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An  Interface  to  the  ARPA  Network 
for  che  CP/CMS  Time-sharing  System 


Introduction 


[aCe  t0  the  ARPA  network  consists  of  a  Network 
PrograB  <NCP>  “hich  handles  Host  to  Host 
communications,  a  LOGGER/SERVER  for  providing  access  to 

al,*achine  froffi  the  network,  and  a  user 
subroutine  package  for  communicating  with  other  Posts  on 

„ner.r^t,'orA  f5°®  a  iogded  on  CP  virtual  machine 

LorrPR1^^111  th€-  C"S  environ®ent.  The  NCP  and  the 
LOGGER  each  run  m  separate  virtual  machines;  the  NCP 

hanlnt^9  the  Ii'~  °?Grations  eith  the  IHP  and  the  LOGGER 
handling  pseudo  I/O  operations  with  CP  throuqb  a 
..oftware  supported  virtual  terminal  device.  CHS  virtual 

thrrtnrtk^  communicate  with  the  NCP  virtual  machine 
through  a  special  virtual  machine  to  virtual  machine 
communications  facility.  “e 

j gi  w®re  written  in  assembly  language  for  the 

IBM  36C/67  system  and  operate  with  CHS  in  a  CP  virtual 
machine  environment. 

description  of  the  ARPA  network  is  qiven, 

fvitem  d  ThL  an  ?“tlln®  of  the  CP/CMS  time-sharing 
system.  This  provides  the  fram  work  for  a  more  detailed 

consideration  of  the  interface  software  and  the 
omatic  initialization  and  error  recovery  features 
that  are  incorporated  in  the  system  design. 


2.  The  ARPA  Network 
2. 1  General  Description 


Network  is  a  store  and  forward,  message 

larnc  i*RetW°tK  *'hich  interconnects  a  number  of 
processing  computer  systems  throughout  th® 
arflinkiff’  The  computer  systems,  known  as  HOSTs, 
k  ^  together  for  the  purpose  of  sharing  resources 
among  member  sites.  (See  ROBERTS  6  WESSLEF,  Ref.  17) 
At  each  node  of  the  network  is  an  Interface  Nessaqe 
or  I®1F  whlch  controls  all  traffic  through  the 
Rot6'  Q  feeT  “EiRT'  KAHN»  ORNSTEIN,  CROMTHER  6  MALDEN, 
know*  IMPs  are,  interconnected  by  wide-band  (50 

ninwfao %  P6fw  second)  leased  communication  lines  and 
Hn^td  f°C  tl!e  c?nnectlon  to  the  network  of  up  to  four 

H  vwell  ennn  The  lflP  is  a  sightly  modified 

n  CDP'-16  computer  and  has  been  developed  by 

BuLT,  BERANEK  &  NEWMAN  (Ref.  1)  .  P  J 


The  topology  of  the  network 
implemented ,  was  as  shown 
computer  systems  connected 
of  Fig.  3. 


at  the  time  the  system  was 
in  Fig,  1  and  Fig.  2.  The 
were  as  listed  in  the  table 
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Fig.  3:  Hosts  on  the  ARPA  Network  -  July  1971 
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Since  that  time,  the  network  has  been  expanded,  and  a 
more  recent  status  report  is  given  in  KIRSTEIN  (Ref, 
10) . 

•2  Network  Concepts 

The  HOST  computers  typically  differ  from  one  another  in 
type,  spead,  word  length  and  operating  system,  though 
the  notion  of  multiprogramming  dominates  most  of  the 
systems.  Such  HOSTS  could  concurrently  support  several 
users,  with  each  user  running  one  or  more  processes.  A 
'process’,  in  this  context,  is  taken  to  mean  any 
software  entity  in  a  HOST  with  which  ar  instruction 
counter  is  associated,  and  includes  each  concurrent 
activation  of  a  re-entrant  program.  7.t  corresponds 
closely  to  the  term  •activity1  used  Ly  SPOONER  (Ref. 
18)  . 

A  fundamental  requirement  of  the  design  is  to  provide 
for  proeess-to- process  communication  over  the  network. 
It  was  decided  that  such  communication  should  be  based, 
not  on  a  solitary  message,  but  rather  upon  a  seguence  of 
messages  and  that  this  sequence  should  conform  to  some 
standard  formatting  procedure  or  •protocol*.  A  number  of 
such  process- to-process  protocols  have  been  defined  and 
i ncluded: 

a.  An  Initial  Connection  Proto*  »»l  (ICP)  which  enaoles 
any  process  to  gain  access  to  specific  processes 
(such  as  the  system  logger)  at  another  HOST. 

b.  A  Telecommunication  Network  (TELNET)  protocol 
which  enables  any  terminal  serving  process  to  be 
connected  to  any  remote  keyboard-printer  terminal 
by  mapping  through  a  Network  Virtual  Terminal 
( NVT)  . 

c.  A  Data  Transfer  protocol  which  specifies  standard 
methods  of  formatting  data  for  transmission 
through  the  network. 

d.  A  File  "'-c.nsfer  protoc<  which  specifies  methods 
for  leading,  writing  and  updating  files  sorted  at 
a  remote  POST. 

e.  A  Graphics  protocol  which  facilitates  the  transfer 
of  graphics  display  information^ 

Processes  which  desire  to  communicate  with  one  another 
have  to  be  coupled  by  cne  or  more  •connections*.  A 
connection  is  defined  to  be  simplex  (uni-directional) 
and  connects  an  output  port  of  one  process  to  an  input 
port  of  another.  Once  such  a  connexion  has  been 
established,  messages  passed  to  the  output  port  of  one 
process  are  automatically  received  at  the  input  port  of 
the  other. 
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Difficulties  exist  in  uniquely  identifying  ports 
(network-wide)  in  that  each  HOST.,  typically,  has  a 
different  internal  scheme  for  naming  its  processes.  For 
this  reason,  a  standard,  intermediate  name  space  is 
used,  with  a  separate  portion  of  the  name  space 
?.llocated  to  each  HOST.  The  elements  of  the  name  space 
are  called  ‘sockets1  and  each  HOST  is  responsible  for 
mapping  sockets  to  ports  for  its  own  internal  processes. 
A  socket  is  specified  by  a  40-bit  number,  the  first  8 
bits  of  which  identified  the  HOST.  In  the  Lincoln 
Laboratory  implementation,  a  further  24  bits  are  used  to 
identify  the  internal  process  and  the  reamining  8  bits, 
the  port  within  the  process.  The  ‘gender1  of  the  socket 
(that  is,  whether  it  is  send  or  receive)  is  marked  by 
the  lest  bit,  thus  giving  each  process  a  maximum  of  128 
send  and  128  receive  sockets. 

Although  it  would  be  possible  for  processes  to  establish 
connections  on  their  own  behalf,  it  is  considered 
desirable  that  control  be  co-ordinated  in  a  standard 
manner,  throughout  the  network,  by  a  special  purpose 
Network  Control  Program  (NCP)  resident  in  each  HOST. 
Processes  within  a  HOST  then  communicate  with  the  rest 
of  the  network  through  their  local  NCP,  which 
establishes,  breaks,  and  controls  data  flow  over 
connections  as  required. 

In  order  to  ac;omplish  its  tasks,  the  NCP  of  one  HOST  is 
required  to  communicate,  in  a  well-defined  manner,  with 
the  NCP s  of  other  HOSTs.  To  this  end  a  HOST-to-HOST 
protocol  was  defined  by  the  Network  Working  Group  (NWG) , 
which  specifies  methods  of  establishina  and  breaking 
ccmmunica tions  paths,  the  managing  of  buffer  space,  and 
a  method  of  providing  interrupt  facilities.  This 
protocol  is  known  as  the  ‘second- level  protocol*  and  is 
transparent  to  the  higher  level  process-to-process 
protocols  outlined  previously. 

ihe  medium  for  communication  between  HOSTs  is  \.he 
•link*.  Every  HOST  is  considered  to  have  256  receive 
links  frei  every  other  HOST,  which  the  NCP  could  assign 
to  connections  as  required.  Links  are  permanently 
available  to  the  NCr  and  are  specified  by  the  8-bit  HOST 
identifiers  concatenated  with  an  8-bit  link  number.  Link 
number  0  is  used  throughout  the  network  as  the  'co;itrol 
link1,  over  which  NCPs  can  issue  ‘control  messages1  to 
one  another  in  accordance  with  the  standards  specified 
by  the  second  level  protocol.  Control  messages  are 
always  interpreted  by  an  NCP  as  a  sequence  of  one 
more  ‘control  commands1  to  effect  such  activities  as  the 
initiation  of  a  connections,  the  assignment  of  buffer 
space,  or  the  notification  of  an  interrupt. 

Each  NCP  maintains  a  ‘rendezvous*  (EV)  table  wh^h 
recoras  the  current  assignment  of  sockets  to  internal 
Fr  cesses  and  links  to  connections.  Incoming  messages 
on  a  link,  other  than  link  0,  are  passed  by  the  NCP  to 
*hat  port  of  that  internal  process  specified  by  an 
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appropriate  entry  in  the  BV  table.  If  no  such  entry 
exists,  the  message  is  rejected.  Outgoing  messages, 
from  t  n  internal  process,  are  associated  with  the 
appropriate  link  number,  obtained  from  the  BV  table, 
before  being  transmitted  to  the  appropriate  HOST. 

In  order  to  effect  any  transmission  of  messages,  via  the 
network,  an  NCP  has  to  communicate  with  its  local  IMP, 
A  well  defined  procedure,  known  as  the  HOST-to-IMP  or 
'first  level'  protocol,  has  been  specified  for  this 
purpose.  Two  types  of  messages  are  permitted  by  this 
protocol: 

a.  |Hegular|  messages  which  are  always  associated 
with  a  link  and  which  are  passed  by  the  IMPs, 
through  the  network,  to  a  destination  HOST.  Such 
messages  provide  the  mechanism  for  all  HOST  to 
HOST  communication. 

b.  'Irregular'  messages  which  are  communications 
between  a  HOST  and  its  local  IMP.  Such  messages 
are  not,  in  general,  passed  through  the  network  to 
a  distant  HOST,  but  are  used  for  local  control 
purposes. 

The  protocol  is  implemented  through  the  medium  of  a 
32-bit  'leader',  appended  to  all  messaaes.  Fields  in 
the  leader  specify  the  message  type,  the  destination  or 
source  HOST  and  the  link  number.  Regular  messages  are 
of  message  type  0,  and  irregular  messages  are  of  type 
non-zero,  the  particular  value  of  the  type  defining  the 
function  of  the  irregular  message.  The  protocol  is 
transparent  to  the  higher  level  HOS^-to-  HOST  and 
process-to- process  protocols  referred  to  above. 

Any  regular  message,  passed  by  a  HOST  to  its  local  IMP, 
is  split,  by  that  IMP,  into  one  or  more  'packets'  for 
transmission  through  the  network.  Bach  packet  is 
preceded  by  a  64-bit  routinq  'header*  which  contains 
such  information  as  the  destination  and  source  HOSTS, 
the  link  number,  the  message  and  packet  numbers  and  a 
set  of  flags. 

A  packet  is  passed,  from  IMP  to  IMP,  throuah  the  network 
untiL  it  reaches  its  destination,  as  specified  in  its 
he^ei.  Each  intermediate  iNp  selects  the  next  leg  of 
the  transmission  path,  for  the  packet,  on  the  basis  of 
network  topology,  local  tr  Cfic  density  and  current  line 
qualities.  The  destination  IMP  reconstructs  the  message 
from  the  individual  packets,  re-erdering  them  as 

necessary  in  accordance  with  the  packet  numbers.  Such 
re-ordering  is  required  because  of  the  potentially 
liferent  routes,  and  hence  different  transmission 
times,  taken  by  each  packet,  when  the  messages  have 
been  reconstructed,  the  destination  IMF  passes  it  to  the 
destination  HOST  and  transmits  an  acknowledgement 
message  to  the  source  IMP.  This  acknowledgement  message 
is  known  as  a  Beady  For  Next  Message  (P  FNM ) •  On 

7 


receipt  of  the  RFNM ,  the  source  IhP  advises  the  source 
HOST  that  the  message  had  been  passe*  and  that  the  link 
associated  with  it  is  now  free  for  further 
transmissions.  The  packet  mechanism  and  the  IMP  to  IMP 
communication  procedures  are  transparent  to  all  the 
higher  level  protocols. 

At  the  hardware  level,  a  HOST  is  connected  to  its  IMP  by 
a  specially  designed  interface,  across  which  information 
can  be  transmitted,  bit  serially,  in  either  direction. 
It  is  this  interface  which  resolved  the  differences  in 
word  lengths  and  speeds  between  the  HOSTs  and  IMPS, 
Transmissions  consist  of  a  bit  train,  containing  no 
special  indication  of  word  or  byte  boundaries,  but 
interrupted  as  required  while  the  sender  fetches  a  new 
word  from  memory,  or  the  receiver  writes  an  assembled 
ere  into  storage. 

The  Lincoln  Laboratory  360/67  is  connected  to  the  IMP 
through  a  specially  built  interface  box.  This  box  is 
attached  as  a  control  unit  on  the  multiplexer  channel 
and  provides  a  duplex  connection  to  th»  IMP,  Thus  the 
IMP  appears  as  two  devices,  one  for  transmission  of  data 
and  one  for  the  reception  of  data,  both  of  which  can 
operate  simultaneously.  The  specifications  of  data 
transfer  to  and  from  the  IaMP  through  this  interface  box 
is  described  in  Appendix  ft. 


2.3  Requirements  of  the  HOST  Software 

The  network  control  software,  resident  in  ^ach  HOST,  is 
required  to  observe  five  major  interfaces  and  effect  the 
protocols  associated  with  them.  These  ar-  : 

a.  The  hardware  interface  between  a  HOST  and  its  IMP, 
and  the  protocol  which  specifies  the  control  of 
that  interface. 

b.  The  software  interface  between  a  Network  Control 
Program  and  its  local  IMP ,  and  the  i'OST-to-IMP 
protocol. 

c.  The  software  interface  between  Network  Control 
Programs,  and  the  H CST-to -HOST  protocol. 

d.  The  software  interface  between  and  internal 
process  and  its  local  Network  Control  Program,  and 
the  protocol  which  describes  the  form  of  messages 
between  them. 

e.  The  software  interface  between  orocesses,  and  the 
various  procecs-to-process  protocols. 

Of  these  protocols,  the  HOST-to-IMP,  HOST-to-HOST  and 
prccess-to- process  are  network  defined;  the  remainder 
are  implementation  dependent  and  vary  in  detail  from 
site  to  site.  An  outline  description  of  the  network 
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defined  protocols  follows;  the  implementation  dependent 
ones  are  described  in  Section  4, 

2.4  HOST- to-I MP  Protocol 

The  HOST-to-IMP  protocol  was  specified  by  BOLT,  EEPANEK 
&  NEWMAN  (Ref.  2)  who  designed  the  IMP  software  and 
modified  the  Honeywell  DDP-516  computer.  This  protocol 
is  based  on  the  concepts  of  a  'message1  and  a  'link*. 

A  message  consists  of  not  more  than  8096  bits  of  data 
which  includes  32  bits  for  a  leader  and  at  least  one  bit 
for  ‘padding*. 

Padding  is  added  by  the  hardware  interfaces  to  resolve 
the  word  length  mis-match  problem  of  dissimilar  HOSTs 
and  IMPS.  The  source  HOST  to  IMP  interface  appends  a 
single  one  bit  to  the  end  of  a  message,  followed  by 
sufficient  trailinq  zero  bits  to  complete  an  integral 
number  of  IMP  words.  The  destination  IMP  to  HOST 
interface  appends  additional  trailing  zero  bits  to 
complete  an  integral  number  of  destination  HOST  words. 
The  end  of  the  message  can  thus  be  located  by  a 
destination  HOST  by  searching  its  input  buffer,  back 
from  the  last  word  transferred,  until  it  finds  a 

non-zero  bit.  The  bit  prior  to  this  will  be  the  last  bit 
of  the  messaqe  sent  by  the  source  HOST.  No  network 
significance  is  to  be  placed  on  HOST  word  or  byte 

boundaries. 

Two  classes  of  message  type  are  specified,  as  stated 
previously;  regular  messages  which  have  a  zero  message 
type  and  which  provided  the  medium  for  all  HOST  to  HOST 
communications;  and  irregular  messages  which  have  a 
non-zero  message  type  and  which  are  used  for  control 
pu-poses  hPtween  a  HOST  and  its  IMF.  (It  should  be 
ru  ed  that  messages  of  non-zero  messace  type  are 
referred  to  in  BOLT,  B  ERA  NEK  &  NEWMAN  (Ref.  2)  as 

‘control  messages* .  This  term  is  also  used  in  the 

KOST-to-HOST  protocol  for  regular  messages  on  link  zero. 
To  avoid  ambiguity,  the  term  ‘irregular  message*  is  used 
throuqhout  this  report  to  refer  to  messages  of  non-zerc 
message  type,  and  the  term  ‘control  messaqe'  is  reserved 
for  HOST-to-HOST  protocol  use.) 

The  32-bit  leader  determines  the  type  of  the  message  and 
the  link,  if  any,  with  which  it  is  to  be  associated 

(Fig.  4) , 

Regular  messages  are  always  to  be  associated  with  a  link 
and  this  is  fully  specified  by  a  destination  HOST 

identifier,  a  source  HOST  identifier,  and  a  link  number. 
Of  these,  the  originating  HOST  specifies,  explicitly, 
only  the  destination  HOST  identifier  .in  the  HOST 
identifier  field,  and  the  link  number.  At  its 

destination,  the  destination  IMP  regenerates  the  leader 
from  the  packet  header,  replacing  the  value  originally 
in  the  HOST  identifier  field  by  the  source  HOST 
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identifier.  Once  a  message  had  been  assigned  to  a  link, 
the  link  is  said  to  be  blocked*  and  the  IMP  will  refuse 
further  transmissions  over  it  until  the  first  message 
has  either  been  delivered  or  rejected.  Notification  of 
these  events  is  by  irregular  IMP  to  HOST  messages;  a 
type  five  indicating  successful  delivery  (RPNM)  ;  a  type 
seven,  that  the  destination  HOST  did  not  receive  the 
complete  transmission.  Each  of  these  messages  unblocks 
the  link.  Other  irregular  messages  in  the  protocol 
enable  an  IMP  to  indicate  to  its  HOST  that  a  link  is 
blocked;  that  errors  have  been  noted  in  previous 

messages;  or  that  its  link  table  is  full.  The  HOST  can 
indicate  to  its  IMP  that  it  is  closinor  down;  that  errors 
have  been  noted  in  previous  messages;  or  that  a 
particular  message  is  for  test  purposes  only.  The 
messages  are  summarized  in  Fig.  4  and  described  in  more 
detail  in  Appendix  B  and  C. 

With  reference  to  the  leader,  the  FLAGS  field,  of  four 

bits  width,  is  set  to  zero  by  source  HOSTs  and  ignored 

by  destination  HOSTs.  The  field  is  to  be  used  only  to 
communicate  with  IMP  background  programs  for  diagnostic, 
maintenance  or  measurement  purposes.  The  fields, 

MESSAGE  TYPE  (four  bits)  ,  HOST  IDENTIFIER  (eight  bi+s) 
and  LINK  NUMBER  (eight  bits)  ar»  to  be  used  as  described 
abova.  The  remaining  eight  bits  of  the  leader  are 
unassigned.  The  DATA  field,  of  variable  width,  is 
unused  in  irregular  messages  and  is  formatted  according 
to  the  HOST-to-HOST  protocol  conventions  i :»  regular 
messages. 

The  IMPs  exercise  traffic  control  and  restrict  the  total 
amount  of  data  in  transmission  through  tne  network  by: 

a.  Refusing  additional  messages  ov^r  a  ‘blocked* 
link. 

b.  Limiting  the  maximum  size  of  a  message  to  9096 
bits. 

c.  Limiting  to  63  the  number  of  transmit  and  receive 
links  a  HCST  can  concurrently  have  active. 

d.  Rejecting  any  message  which  required  longer  than 
15  seconds  for  re-assembly  from  its  constituent 
pack**  ts . 

e.  Rejecting  any  message  which  has  not  been  collected 
by  a  destination  HOST  within  40  seconds  of 
re-assembly. 

The  constraint  of  a  regular  message  tc  net  more  tha. 
8096  bits  in  length  is  imposed  by  the  IMP  sub-network. 
The  second-level  or  HOST-to-HOST  protocol  passes  this 
constraint  to  the  user  process. 


11 


I 

I  FILLER  (M3) 

I 

|  variable 


Fig.  5:  HOST-to-riOST  Message  Format 


2 .  c>  HOST-to - HOST  Protocol  and  the  NCP 


An  early  design  for  the  HOST-to-HOST  protocol  was 
reported  on  in  CARP,  CROCKER  6  CERF  (Ref.  4) ,  but  the 
version  implemented  was  formulated  by  the  Network 
Workino  Group  and  is  specified  in  CPOCKFF  (Ref.  7). 

This  protocol  is  based  on  the  concept  of  a  HOST-resident 
Network  Control  Program  (NCF),  which  can  communicate 
with  other  HOST-resident  Netsork  Control  Programs,  by 
means  of  ‘control  messages',  issued  over  'control 
links',  for  the  purpose  of  effecting  'connections' 
between  'sockets'  assigned  to  HCST-resident  processes. 

All  HOST-to-HOST  communications  are  regular  messages, 
control  messages  being  sent  over  link  zero  and 
interprocess  transmissions  over  non-zero  links.  The 
transmitting  NCP  is  responsible  for  segmenting 
interprocess  transmissions  into  regular  messages,  not 
more  than  8096  bits  in  length.  The  receiving  NCP  is 
therefore  responsible  for  concatenating  successive 
regular  messages  into  a  single,  or  differently  divided, 
transmission  for  delivery  to  the  receiving  process. 
Recause  of  the  differing  word  lengths  of  the 

CCS  muni  :ating  HOSTS,  the  DATA  field  of  regular  messages 
(Fig,  4)  will  not,  necessarily,  start  or  end  on  word 
bo  idaries  at  the  receiving  HOST.  In  order  to 
concatenate  successive  regular  messages,  the  receiving 
NCP  nas  to  be  prepared  to  employ  extensive  bit  shifting; 
an  expensive  operation  in  terms  of  processor  time.  To 
alleviate  this  situation,  the  notions  of  a  'message 
header'  and  a  'connection  byte  size'  have  been 

introduced. 

The  message  header  embraces  the  regular  message  leader 
and  extends  the  required  information  at  the  beginning  of 
each  message  to  a  total  of  72  bits.  The  figure  of  72 
was  chosen  as  the  lowest  common  multiple  of  most  HOST 
byte  and  word  lengths;  these  being  8,  18,  ?4  and  36 

bits.  This  header  reduces  the  bit  shifting  problems,  at 
the  beginning  of  a  message,  for  the  majority  of  HOSTs. 
The  format  of  the  header  is  given  in  Fig.  5. 

It  consists  of  the  32-fcit  leader,  specified  by  the 
HOST-to-IMP  protocol;  an  8-bit  filler  field  (Ml);  an 
8-bit  connection  byte  size  field  (S)  ;  a  16-bit  number  of 
bytes  field  (C)  and  a  further  8-bit  filler  field  (M2). 
The  text  field  of  a  message  consists  of  C  bytes  each  of 
S  bits  per  byte.  It  was  decided  that,  for  each 
connection,  a  connection  byte  size  should  be  agreed 
upon,  by  the  communicating  procedures,  and  that  this 
would  typically  be  the  lowest  common  multiple  of  the 
respective  KCST  word  lengths.  The  text  of  messages 
would  then  be  an  integral  number  of  these  bytes.  This 
procedure  reduces  the  bit  shifting  problems  at  the  end 
of  a  message.  In  addition,  a  variable  lenoth  filler 
field  (M3),  is  specified  at  the  end  of  a  message  which 
can  be  used  by  the  transmitting  HOST  to  fill  the  message 
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Fig,  6:  HOST-to-HOST  Control  Commands 


out  to  a  word  boundary.  All  the  filler  fields  have  a 
zero  value. 

A  connection  byte  size  is  specified  when  the  connection 
is  first  established,  on  behalf  of  processes,  by  the 
co-operating  NCFs.  Connections  between  HCPs  ,  on  links 
number  zero,  are  not,  however,  explicitly  established 
but  are  considered  to  exist  when  a  HOST  becomes  active. 
The  connection  byte  size  for  these  connections  is 
implicitly  defined  to  be  8  bits,  and  the  text  field 
always  consists  of  an  integral  number  of  control 
commands. 

The  format  for  each  control  command  is  given  in  Fig.  6; 
the  first  field  of  8  bits.  Known  as  the  ‘op-code', 
defines  the  function  of  the  command  and  successive 
fields  specify  parameters  to  it.  The  figure  sh^s  the 
three  character  mnemonic  name  of  each  op-code;  its 
numeric  value  in  parentheses;  the  size  of  the  parameter 
fields  ana  the  type  of  parameters  required.  Op-codes 
are  defined  l'or  such  functions  as  the  establishment  of  a 
connection,  RTS  (receiver  to  sender)  and  STR  (sender  to 
receiver);  the  termination  of  a  connection,  CIS  (close); 
the  control  of  buffer  space,  ALL  (allocate),  GVE  (give 
back)  and  RET  (return) ;  the  notification  of  interrupts, 
I  NR  (interrupt  receive  link)  and  INS  (interrupt  send 
link) ;  tne  reporting  of  errors,  ERP  (error)  and  the 
determination  of  status,  ECO  (echo),  EFP  (echo  reply), 
FST  (reset)  and  RRP  (reset  reply) . 

When  two  processes  desire  to  establish  a  connection,  the 
prospective  sender  requests  its  NCP  to  issue  an  STR 
command  and  the  prospective  receiver  requests  its  NCP  to 
issue  an  RTS  command.  The  STR  command  specifies  the 
local  send  socket,  the  foreign  receive  socket  and  a 
connection  byte  size.  The  hTS  command  specifies  the 
local  receive  socket,  the  foreign  send  socket  and  a 
previously  unassigned  link  number  for  use  by  the 
connection.  Once  these  commands,  known  as  ‘requests  for 
connections*  (RFCs) ,  have  been  exchanged,  and  provided 
that  the  specified  sockets  match  and  were  net  already  in 
use,  the  NCP  of  the  prospective  receiver  issues  an  ALL 
ccnmand  specifying  the  amount  of  buffer  space  it  is 
prepared  to  assign  to  the  connection.  On  receipt  of  this 
command,  the  NC F  of  the  prospective  sender  is  permitted 
to  transmit  data,  on  behalf  of  its  process,  up  to  the 
ameunt  specified  in  the  command.  It  is  expected  that  as 
the  NCP  of  the  prospective  receiver  passes  the  data  to 
its  process  and  releases  its  internal  buffer  space,  it 
will  issue  further  ALL  commands  to  the  sender,  to  enable 
transmissions  to  continue.  The  NCP  of  the  prospective 
receiver  can,  at  any  time,  request  a  return  of  all  or 
part  of  the  buffer  allocation  by  means  of  a  GVB  command 
and  this  is  to  be  acknowledged  by  a  PET  command.  All 
NCPs  are  to  maintain  message  and  bit  counters  for  each 
of  their  send  connections  which  are  to  reflect  the 
current  buffer  allocation  at  the  receiving  site.  They 
are  specifically  prohibited  from  issuing  any  message 
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which  would  result  in  either  counter  fceing  decremented 
below  zero.  This  flow  control  mechanism  does  not  apply, 
however,  to  control  messages  issued  on  links  number 
zero. 

Connections  can  terminate  by  either  NC?  issuing  a  CLS 
command  which  the  other  NCP  is  to  echo.  Care  is  required 
to  ensi  re  that  a  CLS  command,  issued  by  a  sending  NCP  on 
link  zero,  does  not  arrive  at  the  receiving  NCP  before 
the  last  data  message  on  the  connection  to  which  it 
refers. 

An  NCP  is  permitted  to  issue  an  ERR  command  whenever  it 
detects  a  HOST-to-HOST  protocol  error  by  another  NCF. 
The  code  field  of  this  command  specifies  the  type  of  the 
error  and  the  data  field  gives  additional  information 
about  it.  A  number  of  error  types  are  network  defined 
but  it  is  expected  that  implementers  of  NCPs  would 
publish  details  of  their  own  additional  error  types. 
{See  Section  4)  . 

Further  details  of  the  HCST-to-HOST  protocol  are  given 
in  Appendix  E, 

.6  Process -to-Process  Protocols 

Two  process-to-process  protocols  were  defined  at  the 
time  the  system  to  be  described  was  implemented;  the 
Initial  Connection  Protocol  (ICP)  and  the 
Telecommunication  Network  protocol  {TELNET)  •  These 
protocols  are  used  both  by  the  LOGGER  SERVER  and  the 
user  TE1NET  processes  discussed  in  Section  4. 

A  family  of  ICPs  is  formally  specified,  on  behalf  of  the 
Network  Working  Group,  by  .OSTEL  (Ref.  15).  The 
prctocois  reguire  a  'listen'  function  to  be  defined 
which  permits  a  process  to  specify  to  its  local  NCP  the 
identity  of  a  sccket  for  which  it  is  prepared  to  accept 
a  connection  frem  any  other  process.  Cn  receipt  of  an 
appropriate  request  for  connection  to  such  a  socket,  the 
lccal  NCP  is  to  issue  the  matching  RFC ,  thus  completing 
the  connection,  and  to  advise  its  process  accordingly. 
This  function  is  effected  in  the  Lincoln  Laboratory 
system  by  the  process- to-NCP  command,  enable  connect 
(ENC)  and  enable  listen  (ENL)  described  in  Section  4. 

Using  thij  protocol,  a  server  process  listens  on  one  of 
its  send  sockets,  L,  which  is  well  known  throughout  the 
network.  A  user  process,  wishing  to  communicate  with 
the  server  process,  requests  its  NCP  to  establish  a 
connection  to  L  from  one  of  its  receive  sockets,  U.  On 
establishment  of  the  connection,  which  is  to  have  a  byte 
size  of  32  tits,  the  server  process  has  two  options.  It 
could  either  reguest  its  NCP  to  close  the  connection, 
indicating  that  it  is  not  prepared  to  communicate 
further  with  the  user  process,  or,  it  could  send  a 
single  32-bit  even  number  S,  identifying  a  pair  of 
sockets,  S  and  S+1,  which  are  to  be  used  for  all 
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subsequent  transmissions.  If  the  server  process  adopts 
the  latter  option,  both  processes  are  to  request  their 
respective  NCPs  to  close  the  connection  between  L  and  U 
and  to  establish  new  connections  between  s  and  U«-3  and 
3+7  and  U*-2.  The  protocol  thus  provides  a  means  of 
establishing  duplex  communications  between  process.  The 
well  known  socket,  L,  is  called  the  Initial  Connection 
Socket  and  is  defined  to  be  X '00000001'  for  the  LOGGER 
SERVER,  where  X  signifies  a  hexadecimal  number.  U+2  and 
U4- 3  are  specified  for  use,  rather  than  U  and  U*1,  in 
order  tc  avoid  a  race  condition. 

The  TELNET  protocol,  described  by  0* SULLIVAN  (Ref.  14) 
on  behalf  of  the  TEINET  committee,  was  designed  to  make 
a  process  at  a  using  site  appear  to  a  process  at  a 
serving  site  as  logically  equivalent  to  a  terminal 
directly  connected  co  the  serving  site.  The  protocol  is 
effected  through  the  medium  of  a  Network  Virtual 
Terminal  ( N  VT)  which  normally  uses  a  staidard, 
intermediate  terminal  code.  Both  the  serving  and  using 
processes  map  their  local  codes  to  this  intermediate 
cede  and  must  conform  to  the  conventions  of  the  N VT. 
This  approach  eliminates  the  need  for  a  HOST  to  keep 
information  about  the  characteristics  of  terminals  and 
terminal  handling  conventions  at  other  host  sites. 

The  intermediate  data  code  of  the  N VT  is  defined  to  be 
the  7-bit  ASCII  code  transmitted  in  8-bit  bytes  with  the 
high  order  tit  set  to  zero.  Connections  tetween 
processes  are  established  using  the  Initial  Connection 
Prctccol  and  have  a  connection  byte  size  of  8  bits.  A 
number  of  8—  tit  TEINET  control  codes  are  also  defined, 
each  with  the  high  order  tit  set  to  one.  These  are  used 
for  such  purposes  as  the  notification  of  a  break  or 
reverse  break  signal;  a  request  to  echo  or  cease  echoing 
data  characters,  or  a  warning  to  suppress  local  printing 
of  input  characters.  In  addition,  a  data  type  control 
code  can  be  sent  as  the  first  byte  of  data  over  a 
connection  to  signify  whetner  the  standard  N VT  code  is 
to  be  used  or  some  defined  alternative  such  as  EBCDIC. 
A  special  synchronising  code  is  also  defined,  which  can 
be  inserted  ii  the  data  stream  ~nd  which  is  always 
associated  with  a  network  interrupt  (INS)  command.  This 
enables  stacked  input  to  a  serving  process,  up  to  the 
synchronising  code,  to  be  discarded  or  temporarily 
ignored  by  those  systems  which  recognised  an  'attention* 
key  as  having  a  specified  interrupt  function. 


The  CP/CMS  Time-Sharing  System 

The  Lincoln  Latoratory  CP/CMS  time-sharing  system  is  a 
modifx,..-d  version  of  IBM's  C P-67/CMS  time-sharing  system 
(Ref.  6)  and  consists  of  two  independent  components;  the 
ContLol  Program  (CP)  and  the  Conversational  Monitor 
System  (CMS) .  The  Control  Program  creates  a  set  of 
'virtual  machines'  which  are  time  shared  with  one 
another,  and  the  Conversational  Monitor  System  provides 
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a  conversational  operating  system  which  can  be  used  to 
control  a  virtual  machine, 

A  virtual  machine  is  a  functional  simulation  of  the  real 
IBM  360/67  and  its  associated  input-output  devices.  The 
virtual  memory  and  virtual  devices  of  a  virtual  machine 
are  specified  ty  a  predefined  configuration  which  can 
differ  for  each  virtual  machine.  The  Control  Program 
allocates  the  CFU  resources  of  the  real  '..achine,  for  a 
short  period  of  time,  to  virtual  machines  in  turn,  in 
accordance  with  a  scheduling  algorithm. 

All  ir. put/output  commands  from  a  virtual  machine  are 
trapped  bv  CP  and  translated  to  real  I/O  operations. 
Unit  record  input-output  is  normally  spooled  onto  disk. 
Virtual  memory  is  divided  into  4096-byte  blocks,  held  on 
paging  drums  and  paged  in  and  out  cf  real  memory  as 
required.  Special  hardware  is  provided  cn  the  IBM  360/67 
for  paqing  purposes  which  performs  'dynamic  address 
translation ' . 

CP  maintains  a  record  of  all  permitted  virtual  machines 
and  identifies  each  one  by  means  of  a  USERID.  Associated 
with  this  USERID  is  a  password,  accounting  information 
and  a  table  describing  the  configuration  of  the  related 
virtual  machine.  Provided  that  the  number  of  active 
virtual  machines  is  not  the  maximum  that  the  system  can 
support  at  any  one  time,  a  user  could  request  CP  to 
establish  his  virtual  machine  by  logging  in  on  an 
unassigned  terminal.  "Logging  in"  involves  the  typing 
cf  a  USERID  md  password  which  are  used  to  validate  an 
authorized  user.  The  terminal  enables  a  user  to  control 
his  virtual  machine,  by  means  of  CP  console  functions, 
in  a  manner  similar  to  that  of  an  operator  at  the 
console  of  the  real  machine.  The  virtual  machine 
appears  to  a  user  and  his  programs  to  be 
indistinguishable  from  the  real  machine. 

Having  established  the  virtual  machine,  the  user  can 
employ  CP  console  functions  for  such  purposes  as  the 
Initial  Program  Loading  (IFL)  of  an  operating  system; 
the  display  or  modification  of  any  portion  of  his 
virtual  memory;  The  stopping  or  restarting  of  his 
virtual  machine;  the  sending  of  messages  to  other 
terminal  users,  the  setting  of  special  virtual  machine 
facilities;  and  the  querying  of  CP  for  systems 
informa  tion . 

CMS  is  cne  of  the  operating  systems  which  can  be  loaded 
into  a  virtual  machine  by  means  of  the  IPL  function.  It 
is  a  single  user  conversational  system  which  provides  a 
comprehensive  command  language  and  programming  facility. 
Commands  exist  for  file  creation  and  manipulation, 
program  compilation,  execution  control,  debugging  and 
various  utility  operations. 

The  file  handling  commands  enable  the  user  to  create, 
copy,  move,  combine,  edit,  print  and  erase  disk  files 
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and  other  ccmm^Lds  provided  access  to  tape  unitsr  line 
printers,  card  readers  and  card  punches.  Compilation 
commands  are  available  for  Assembler,  Fortran  IV  and 
PL/1,  and  the  execution  control  commands  allow  the  user 
to  lead  relocatable  object  programs  and  execute  them 
under  terminal  control.  Executing  programs  can  be  halted 
at  pre-determ iaed  points,  examined,  modified  and 
restarted  usirg  the  debug  commands.  Utility  functions 
provide  for  tape  and  disk  copying,  sorting,  dumping  and 
printing. 

An  EXEC  facility  which  includes  substitutable  parameters 
and  conditional  statements  allows  a  set  of  commands, 
stored  in  a  file,  to  be  obeyed  by  the  command 
interpreter.  Control  can  be  transferred  from  the  CMS 
command  interpreter  to  the  CP  console  function 
environment  by  means  of  ir  'attention*  key,  thus 
allowing  looping  programs  to  be  aborted. 

Ecth  CP  and  CM^  commands  can  be  issued  from  the  terminal 
or  called  from  user  programs.  All  the  network  software 
was  designed  to  operate  in  a  virtual  machine 
environment,  under  control  of  the  CMS  operating  system. 


The  Lincoln  Laboratory  IBM  360/67  Network  Software 

Support  for  the  ARPA  network  on  the  IBM  360/67  computer 
at  Lincoln  Laboratory  is  provided  through  a  Network 
Control  Program  (NCP)  which  runs  in  a  virtual  machine  of 
the  CP-67  operating  system.  The  NCP  virtual  machine  has 
direct  access  to  the  Interface  Message  Processor  (IMP) , 
and  hence  to  Mie  network,  and  communicates  with  other 
virtual  machines  over  a  pair  of  virtual  devices,  one  for 
sending  and  one  for  receiving.  The  virtual  device  used 
for  sending  can  be  directed  to  a  particular  virtual 
machine  in  the  same  way  that  user  virtual  machines 
direct  transmission  to  the  NCP  virtual  machine. 
Transmissions  to  the  NCP  are  identified  as  to  the 
sending  user  and  thus  re  appropriately  processed  by  the 
NCP. 

The  implementa tic n  of  the  NCP  in  a  virtual  machine 
rather  than  as  part  of  the  core  resident  system 
facilitated  its  development  since  it  cculd  operate 
independently  of  other  virtual  machines  and,  hence,  not 
impact  the  reliability  of  the  operating  system.  The  NCP 
is  written  as  a  user  program  which  calls  cn  CMS  system 
facilities  for  program  initialization,  including  program 
re-initialization  in  the  event  of  a  catastrophic  error, 
for  disk  file  services,  and  for  virtual  machine  to 
virtual  machine  communications. 

By  operating  the  NCP  in  a  virtual  machine,  core  memory 
is  not  dedicated  to  support  the  network  operation; 
system  resources  are  only  required  when  network  activity 
occurs.  In  addition,  operating  the  NCP  in  a  virtual 
machine  is  particularly  convenient  since  the  protocol  by 
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which  NCP's  communicate  is  being  changed  and  will 
continue  to  evolve.  The  added  overhead  to  the  operation 
of  the  NCP  caused  by  these  techniques  does  not  preclude 
useful  network  operation  and  experimentation.  A  number 
of  improvements  can  be  implemented  to  reduce  this 
overhead  by  giving  the  HCP  special  priorities  if  the  use 
of  the  network  is  limited  by  the  performance  of  the  NCP. 

The  NCP  keeps  a  table  (the  rendezvous  table  -  RV  table) 
whose  entries  reflect  the  state  of  connections  between 
the  local  NCP  and  a  foreign  NCP.  Each  entry  contains 
the  identification  of  a  foreign  socket  and  a  local 
socket,  and  the  userid  of  the  local  virtual  machine 
which  is  to  te  associated  with  the  local  socket. 
Entries  are  made  in  the  RV  table  either  on  the  receipt 
of  a  Request  For  Connection  (RFC)  control  message  from  a 
foreign  NCP  or  through  a  request  from  a  local  virtual 
machine. 

The  communication  protocol  between  a  user  virtual 
machine  and  the  NCP  resembles  the  NCP  to  NCP  protocol. 
Data  cannot  be  transmitted  until  a  connection  is 
initiateu  by  both  the  sender  and  the  receiver  and  the 
NCP  to  NCP  requirements  for  flow  control  are  met.  The 
NCF  specifies  the  number  of  bits  it  is  prepared  to 
buffer  for  a  receive  conn*  r  ion  and  stores  messages 
received  from  a  foreign  NCP  until  a  local  user  makes  a 
request  for  a  message.  If  no  message  has  been  receiveu 
when  a  user  makes  a  receive  request,  this  fact  is 
returned  to  the  user.  The  NCP  will  not  accept  a  message 
from  a  user  for  tranmission  if  the  receiving  NCP  has  not 
provided  adequate  buffering.  In  this  way,  the 
requirements  for  flow  control  between  NCP  and  NCP  are 
passed  to  the  user.  The  NCP  also  notifies  the  user  of 
any  asynchronous  change  in  the  state  of  a  connection  so 
that  he  can  take  appropriate  action.  For  example,  the 
user  is  notified  a)  when  a  connection  he  has  initiated 
has  been  completed  by  the  foreign  host,  b)  when  a 
message  is  received  and  there  had  net  been  any  previous 
messages  buffered,  and  c)  when  a  connection  is  closed  by 
the  foreign  host.  In  addition,  the  user  is  notified 
when  a  network  interrupt  has  been  received  for  the 
connection. 

A  set  of  low-level  user  routines  (NET)  have  been 
provided  to  communicate  with  the  NCP.  These  routines 
follow  the  protocol  defined  for  network  communications 
through  the  NCP.  For  each  user  request  to  the  NCP,  a 
reply  from  the  NCP  is  sent  to  the  user  virtual  machine 
indicating  either  successful  or  unsuccessful  completion 
of  the  request  and  the  current  status  of  the  connection. 
These  routines  handle  the  stacking  of  asynchronous 
interrupts  which  are  unstacked  through  a  ca31  tc  the  NET 
routines. 

One  user  virtual  machine  which  has  been  developed  is  the 
LOGGER  virtual  machine.  The  LOGGER  controls  a  number  of 
virtual  terminals  which  provide  access  to  the  CP  system 
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in  a  manner  similiar  to  physical  terminals,  but  instead 
of  a  hardware  terminal,  CP  is  interfaced  with  a 
specially  designed  virtual  terminal  device  which  is 
driven  by  software.  Thus,  information  normally  typed  on 
a  terminal  by  CP  and  information  normally  keyed  into  a 


termina 1 

is 

transferred  between 

the  LOGGER  and 

CP 

throuqh 

one 

of  these  virtual 

terminal 

devices. 

The 

protocol 

for 

controlling  a 

software 

terminal 

is 

described 

in 

Appendix  E. 

when  the 

LOGGER  is  initialized 

it  is 

prepared 

to 

ccormunicate  with  tne  NCP  over  the  socket  defied  for 
LOGGER  operation  under  the  Initial  Connection  Pr  tocol 
(TCP)  .  Communication  under  th*>  ICP  will  result  in  a  new 
pair  of  sockets  being  defined  throuqh  which  the  LOGGER 
will  provide  CP  services  to  the  network.  Once  this  pair 
of  sockets  is  defined,  the  LOGGER  acts  as  a  SERVE? 
interfacing  a  virtual  terminal  with  a  remote  process 
through  the  NCP. 

During  the  initial  login  sequence,  the  LOGGER  analyzes 
received  network  messages  for  ’userid’  and  'password* 
and  compares  these  with  entries  in  a  special  file.  If 
the  userid  does  not  appear  in  the  file,  an  invalid 
userid  is  passed  to  CP.  If  the  password  matches  the 
network  password  corresponding  to  the  valid  network 
userid  specified  in  the  file,  the  system  password  is 
sent  to  CP.  Since  network  passwords  and  valid  system 
passwords  do  not  have  to  be  identical,  access  to  the  CP 
system  from  the  network  is  specially  controlled  and  may 
be  restricted  to  a  subset  of  authorized  system  users. 
Though  the  operation  of  the  LCGGEF/SERV  ER  as  a  separate 
virtual  machine  introduces  another  level  of  dispatching 
overhead,  this  does  not  appear  to  be  significant  and 
does  not  limit,  its  use. 

4.1  System  Design 

Figure  7  outlines  the  major  elements  of  the  network 
software  and  the  interfaces  between  them. 

The  Network  Control  Picqram  (NCP)  resides  in  a  virtual 
machine  (VM1  in  the  fiaure)  to  which  is  attached  the  IMP 
hardware  interface  and  a  terminal.  The  terminal  is  used 
for  establishing,  and  monitoring  the  activity  of  the 
NCE.  Processes  in  other  virtual  machines  communicate 
with  the  NCP  through  the  CF  virtual  machine  to  virtual 
machine  communications  (VMCOM)  interface.  This  facility 
was  specially  designed  for  efficient  virtual  machine  to 
virtual  machine  communica tions. 

In  an  earlier  version  of  the  network  software,  the  CP 
facility  for  transferring  card  image  from  the  virtual 
card  punch  of  one  virtual  machine  to  the  virtual  card 
reader  of  another  virtual  machine  was  used.  This  process 
used  the  CP  cpoclinu  facility  which  limited  the  rate  of 
virtual  machine  inter-communications  to  the  speed  of 
writing  a  spooled  fil«=  to  the  disk  and  then  reading  the 


Fig.  7:  System  Design 
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spooled  file.  With  the  VMCOM  facility,  data  is  moved 
from  the  virtual  memory  of  one  virtual  machine  to  a  CP 
free  storage  area,  and  then  from  the  CP  free  storage 
area  to  the  virtual  memory  of  another  virtual  machine, 
A  description  cf  the  VMCOM  facility  is  contained  in 
Appendix  ? • 

In  Figure  7,  three  virtual  machines  are  shown  connected 
to  the  NCP  through  the  VMCOM  interface,  VM 3  represents  a 
virtual  machine,  controlled  by  a  user  at  his  terminal, 
executing  a  process  which  is  in  communication  with  the 
network.  All  user  processes  communicate  with  the  NCP  by 
means  of  a  subroutine  and  macro  packaqe,  NET,  which 
effects  a  locally  defined  process-to-NCF  protocol, 

VM2  represents  a  virtual  machine  containing  the 
logger-server  process.  This  process  uses  the  NET 
package  to  communicate  with  the  NCP  and  observes  the 
TELNET  and  icp  process-to-process  protocols  for  all 
network  transmissions,  A  modification  was  made  to  CP, 
by  the  system  maintenance  group,  to  provide  a  CP  virtual 
terminal  interface  for  use  by  the  logger-server.  This 
interface  enables  the  logger-server  to  establish  and 
service  virtual  machines  as  though  it,  itself,  was  a  set 
of  local  terminals  each  controlled  by  a  separate  user. 

The  figure  shows  two  virtual  machines,  VM4  and  VM5, 
established  from  the  network,  by  the  logger-server, 
through  the  virtual  terminal  interface.  Both  virtual 
machines  contain  user  processes  which  are  executing 
under  the  remote  control  cf  network  users  or  their  local 
processes.  In  addition,  VM4  represents  the  case  where 
the  executing  user  process  is  itself  accessing  the 
network  by  means  of  the  NET  package. 

This  design  allows  for  more  complex  configurations  to  ne 
established  than  that  shown  in  the  figure.  Any  number  of 
active  virtual  machines  could  use  the  NET/VMCOM 
interface  and  each  user  process  is  permitted  a  miximum 
of  256  connections  to  the  network.  The  logger-server 
currently  supports  up  tc  three  virtual  machines,  at  any 
one  time,  as  this  is  considered  to  represent  the 
maximum,  in  terms  of  local  resources,  that  should  be 
allocated  to  the  network. 

Brief  descriptions  of  each  of  the  major  elements  follow, 
together  with  seme  implementation  details. 

4.  2  The  NET  Package 

Figure  8  shows  in  block  schematic  form  the  way  in  which 
a  user  process  communicates  with  the  Network  Control 
Program. 

A  set  of  high-level  NET  commands  are  defined  which  can 
be  employed  by  a  process  to  call  subroutines  which  used 
the  NET  package.  Each  high-level  command  is  in  the  form 
of  a  macro,  which  expands  into  one  or  mere  primitive  NET 
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commands.  These  commands,  which  can  be  used  directly  by 
the  user  process,  are  interpreted  by  the  NET  package  and 
issued  as  reguests  to  the  NCP  through  the  medium  of  the 
VMCOM  facility.  Communications  between  NET  and  the  NCP 
consist  of  an  80-byte  control  block  together  with  a  data 
blcck  cf  from  0  to  1024  bytes. 

The  format  of  the  control  block  is  shown  in  Figs.  9,  10, 
and  11  as  a  set  of  field  names,  each  followed  by  the 
field  byte  size  in  parentheses. 

The  CODE  field,  one  byte,  is  used  *.o  specify  the  type  of 
control  block  and  the  remaining  fields  are  used  for 
parameters  set  by  either  NET  or  the  NCP.  The  CODE  is 
given  by  a  numeric  value,  in  the  range  0  to  12,  and  the 
significance  of  each  is  indicated  in  Fig.  12. 

CODES  are  defined  which  allowed  NET  to  reguest  the  NCP 
to: 

a.  Issue,  on  its  behalf,  certain  network  commands 
such  as  STR  (0),  RTS  (1),  CIS  (4),  INS  and  INR 
(6)  . 

b.  Transmit,  on  its  behalf,  interprocess  messages 
over  established  connections  (2). 

c.  Deliver  to  it,  interprocess  messages  from  the 
network  which  the  NCP  had  buffered  until  required 
(3)  . 

d.  Advise  on  the  status  of  particular  sockets  (5). 

e.  Enable  specified  sockets  to  accept  foreign  STRs 
(9)  or  RTSs  (10)  without  having  to  know  in  advance 
the  foreign  socket  numbers.  (The  •listen*  function 
referred  to  in  Section  2.6). 

f.  Disable  sockets  which  previously  had  been  enabled 

(11). 

g.  Purge  all  local  references  to  connections  not 
correctly  closed  by  foreign  HOSTS  (12). 

The  NCP  replies  to  each  NET  request  with  a  reply  control 
block  (7)  which  contains  appropriate  status  information 
in  certain  of  its  parameter  fields.  When  the  NET  request 
is  for  the  delivery  cf  an  interprocess  message  (3),  the 
reply  control  block  is  followed  by  a  data  block,  which 
represented  the  message.  The  NCP  can  also  pass 
asynchronous  interrupts  to  NET,  at  any  time,  by  means  of 
an  interrupt  control  block  (8) .  A  number  of  interrupt 
codes  are  defined  to  notify  the  process  of  such  events 
as: 

a.  The  receipt  of  a  network  interrupt  (INS  or  INR)  on 
one  of  its  current  connections. 
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NET  TRANSMISSION  CODE  (1) 


USER  ID  (8) _ 

LOCAL  ID  (3)  ~  ") 

LOCAL  TAG  (1) _ ) 

FOREIGN  HOST  117  ) 

FOREIGN  ID  (3)  ) 

FOREIGN  TAG  (1) _  ) 

EIT  COUNT  (2) 

INTERRUPT  CODE  (1) 

STATUS  (^) 


EIT  ALLOCATION  LEFT  (4) 
MESSAGE  ALLOCATION  LEFT  (2) 
CONNECTION  BYTE  SIZE  (1) 


LOCAL  SOCKET  (4) 


FOREIGN  SOCKET  (5) 


Fig.  9:  NET  to  NCP  Control  Message  Format 


CHARACTER  COLE  (4) 


ICCAL  ID  (3)  ) 

LOCAL  I  AG  (1) _ ) 

FOREIGN  HOST  (1)  ) 

FOREIGN  ID  (3)  ) 

FOREIGN  TAG  (1)_  ) 

r i ag  (i) 


EIT  COUNT  SENT  CR  RECEIVED  (2) 
EUFFER  ADDRESS  (4) 

STATUS  (4) 

BITS  LEFT  (4) 

MESSAGES  LEFT  (2) 

CONNECTION  EYTS  SIZE  (1) 

UNUSED  BYTE  (1) 

ADDRESS  OF  INTERRUPT  STACK  (4) 


TN73-50-I (10) | 
LOCAL  SOCKET  (4) 

FOREIGN  SOCKET  (c) 


Fig.  10:  N FT  Command  Format 


TN73-50-I (11) 

INTERRUPT  COLE  (1) 

NEXT  ENTRY  IN  IMEPFUFT  STACK  (3) 

LOCAL  SOCKET  (4) 

FOREIGN  SOCKET  (5) 

SPARE  (3) 

STATUS  (4) 


Fig.  11:  Interrupt  Stack  Fermat 
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b.  The  acceptance,  by  a  foreign  HOST,  of  a  request  to 
establish  a  send  connection  to  it,  (i.e.,  the 
receipt  of  a  foreign  RTS  which  aeitched  a 
previously  issued  STS)  • 

c.  The  loading  of  NCP  buffers  for  one  of  its  receive 
connections. 

d.  The  closing  of  one  of  its  connections  by  a  foreign 
HOST. 

e.  The  matching  of  ’enabled*  sockets  with  appropriate 
foreign  STRs  or  RTSs. 

f.  The  shutdown  of  the  local  NCP. 

g.  The  resetting  of  any  foreign  NCP  associated  with 
one  of  its  connections. 

The  interrupt  codes  are  listed  in  Fig.  13  and  any 
interrupt  control  block  sent  from  the  NCP  to  NET  would 
contain  one  of  these  codes  in  the  second  byte  of  the  BIT 
CCUNT  field,  which  doubles  as  the  INTERRUPT  CODE  field 
(Fig.  9). 

The  USERID  field  it  employed  by  both  the  NCP  and  NET  to 
identify  the  virtual  machine  associated  with  tho  NET 
request.  NET  accesses  the  CP  USEPID,  cn  behalf  of  its 
process,  and  completes  this  field  accordingly.  Sockets 
are  defined  (Section  2.2)  to  consist  of  an  8  -  bit  HOST 
identifier  concatenated  with  a  32-  bit  socket  number. 
Local  sockets  are  specified  by  the  32- tit  socket  number 
alone,  since  the  local  NCP  can  add  its  own  HOST 
identifier  as  necessary.  The  LOCAL  SOCKET  field  is 
divided  into  LOCAL  ID  and  LOCAL  TAG  fields  for 
convenience  of  mapping  to  process  identifiers  and  ports, 
and  the  FOREIGN  SOCKET  field  is  similarly  divided,  but 
includes  a  FOREIGN  HOST  field.  Eoth  the  LOCAL  SOCKET  and 
FOREIGN  SOCKET  fields  are  normally  completed  by  NET, 
except  in  the  case  of  enable  requests  where  NET 
completes  only  Hie  LOCAL  SOCKET  field  and  the  NCP  issues 
an  interrupt  control  message,  when  the  enabled  socket  is 
matched,  with  the  FOREIGN  SOCKET  field  completed.  The 
BII  COUNT  field  is  used  by  NET  when  sending  an 
interprocess  message  to  the  NCP  and  by  the  NCP  when 
delivering  an  interprocess  message  to  NET. 

The  STATUS  field  is  always  completed  by  the  NCP  whenever 
it  issues  a  reply  or  interrupt  control  message.  The 
field  is  divided  into  4  groups,  each  of  8  bits;  the 
first  two  groups  describe  the  reply  status  of  the 
previous  NET  request,  and  the  second  twc  grcups  refer  to 
the  connection  status  of  the  associated  entry  in  the  RV 
table.  Each  bit,  when  set,  indicates  that  a  particular 
event  has  occurred  or  a  particular  state  exists  and  the 
significance  of  each  is  given  in  Fig.  14. 
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NET  COMMAND  NCT  CONTROL 

CHARACTER  KESSaGE  DESCRIPTION 

CODE  CODE 

CON  (Connect )"  0  Request  NCF  to  issue  an”sTs7 

LIS  (Listen)  1  Request  NCP  to  issue  an  RTS. 

SND  (Send)  2  Request  NCP  to  transmit  a  buffer. 

RCV  (Receive)  3  Accept  a  buffer  from  the  NCP. 

CLS  (Close)  4  Request  NCP  to  close  a  connection. 

STA  (Status)  5  Request  status  from  the  NCP. 

INT  (Interrupt)  6  Fequest  NCP  to  issue  an  INS  or  INR. 

NOP  (No-operation)  7  Request  status  from  NET.  Reply  code  from  NCP. 

8  Interrupt  code  from  NCP. 

NC  (Enable  connect)  9  Request  NCP  to  accept  a  foreign  STP. 

NL  (Enable  listen)  10  Request  NCP  to  accept  a  foreign  RTS. 

DIE  (Disable)  11  Request  NCP  to  disable  an  enabled  socket. 

PUR  (Purge)  12  Request  NCP  to  purge  an  entry. 


Fig.  12:  NET  Commands 
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INTEFSUPT  MEANING 

CODES 


C  Network  interrupt  received. 

1  Foreign  RTS  received  completing  connection. 

2  Receive  Duffers  now  loaded, 

3  Foreign  CLS  received. 

4  Enable  connect  new  matched. 

5  Enable  listen  now  matched. 

t  NCP  has  died. 

7  Foreign  NCP  Reset  (R ST  received) , 


Fig.  13:  NCP  to  NET  Interrupt  Codes 
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Those  bits  marked  with  an  asterisk  (*)  in  the  RV  status 
are  reset  by  the  NCP  after  it  has  replied  to  an  KCP 
status  request. 

The  BITS  LEFT  and  MESSAGES  LEFT  fields  are  completed  by 
the  NCP ,  whenever  it  replies  to  a  NET  request  associated 
with  a  send  connection,  to  notify  NET  of  the  current 
foreign  allocation  for  that  connection.  The  CONNECTION 
BYTE  SIZE  field  is  completed  b2  NET  for  all  connection 
requests,  though  only  issued  to  the  network,  by  the  NCP, 
for  send  connections,  A  zero  value  on  receive 
connection  requests  implies  acceptance  by  NET  of  any 
connection  byte  size. 

One  advantage  of  this  NCP  mechanism  is  that  a  virtual 
machine,  containing  a  process  in  communication  with  the 
network,  can  be  ‘logged  off'  without  breaking  retwork 
connections.  All  incoming  messages  for  the  process  are 
buffered  by  the  NCP  and  all  information  relating  to 
interrupt  control  messages  are  recorded  in  the  status 
flags.  On  resuming  activity,  the  process  can  determine 
its  current  connections  by  requesting  status  from  the 
NCR  and  can  continue  operations  by  taking  the 
appropriate  action  on  its  connections. 

Figure  10  shows  the  format  of  the  parameter  list  to  be 
used  by  a  process  when  issuing  a  primitive  NET  command 
to  the  NET  package,  ,*ET  is  accessed  by  a  subroutine 
call  which  is  associated  with  a  pointer  to  the  parameter 
list.  The  CHAFAC^  F  CODE  field  cf  the  parameter  list 
contains  the  mnemonic  names  of  the  command  required  and 
this  is  interpreted  by  NET  which  issues  the  appropriate 
control  message  to  the  NCP.  The  mnemonic  names  of  all 
permitted  commands  are  shown  in  Fig,  12  associated  with 
tne  control  message  codes  which  are  generated  by  NET. 
All  commands  cause  the  generation  of  a  control  message, 
with  the  sinqle  exception  of  NOP  which  is  used  to  obtain 
the  NET  interrupt  status.  The  LOCAL  SOCKET,  FOREIGN 
SOCKET,  BIT  COUNT,  STATUS,  BITS  LEFT,  MESSAGES  LEFT  and 
CONNECTION  BYTE  SIZE  fields  are  all  used  for  the  same 
purposes  as,  and  mapped  by  the  NET  package  to,  the 
fields  of  the  same  name  in  the  control  message.  The  FLAG 
field  is  reserved  for  use  by  the  high-level  NET  commands 
and  th*>  BUFFER  ADDRESS  field  contains  a  pointer  either 
to  a  buffer  holding  the  message  for  transmission  in  a 
SND  command  or  to  a  buffer  prepared  for  reception  of  a 
message  in  a  FCV  command. 

NET  maintains  in  free  store  an  interrupt  stack  on  behalf 
of  its  process.  The  ADDRESS  OF  INTERRUPT  STACK  field 
holds  a  pointer  to  the  head  of  this  stack,  each  entry  of 
which  is  to  be  in  the  format  shown  in  Fig.  11.  If  there 
are  no  entries,  the  pointer  has  a  value  of  zero.  NET 
will  read  interrupt  control  messages,  from  the  NCP, 
either  on  receipt  of  a  NOF  command  from  the  user  process 
or  when  awaiting  a  reply  control  message  from  the  NCP. 
Irforraaticn  contained  in  each  interrupt  control  message 
is  transferred  to  the  appropriate  fields  of  a  separate 
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Fig.  14:  Format  of  Status  Bits 
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entry  in  the  interrupt  stack,  the  entries  being  chained 
by  means  of  the  NEXT  ENTRY  IN  INTERROPT  STACK  field. 
The  last  entry  contains  a  value  of  zero  in  this  field. 
It  is  the  responsibility  of  the  user  process  (or  the 
high-level  NET  commands)  to  take  action  on  the  stack 
entries,  to  return  to  free  storage  the  block  associated 
with  each  one  and  to  maintain  the  pointer  in  the  ADDRESS 
OF  INTERROPT  STACK  field. 

In  addition  to  the  full  status  reply  in  the  STATUS  field 
of  the  parameter  list,  a  return  co^e  is  placed  in 
general  purpose  register  15  in  order  to  conform  with  the 
standard  CMS  interface.  This,  together  with  the 
standard  calling  procedure,  allows  the  NET  package  to  be 
used  by  a  process  written  in  any  of  the  languages 
supported  by  the  CMS  system.  See  Appendix  G. 

It  is  expected  that  most  processes  would  access  NET 
through  the  set  of  macros  which  effect  the  high-level 
NET  commands  (see  Appendix  H) .  For  each  connection 
required,  a  NETSOCK  or  NETSOCKV  macro  is  to  be  specified 
which  generates  a  buffer  for  the  NET  command  parameter 
list  (Fig,  1C)  and  associates  identifiers  with  certain 
cf  its  fields.  Before  opening  a  connection  a  NETID 
macro  is  to  be  issued,  which  initializes  the  FLAG  field 
of  the  parameter  list  and  obtains  a  value  for  the  LOCAL 
ID  field  of  the  LOCAL  SOCKET.  The  CP  UTABLE  address  for 
the  virtual  machine  is  used  for  the  ID  field.  A  NETOPEN 
nacre  can  then  be  issued  to  establish  the  connection 
whose  polarity  is  determined  by  the  value  in  the  LOCAL 
TAG  field.  This  can  be  followed  by  NE1READ  or  NET WRITE 
macros,  as  appropriate  to  the  polarity,  in  order  to 
transfer  interprocess  messages.  Flags  (Fig.  15)  are  set 
in  the  FLAG  field  of  the  appropriate  parameter  list, 
associated  with  each  connection,  by  a  routine  which 
analyzes  and  collapses  the  interrupt  stack  each  time  a 
high-level  command  is  issued.  A  NETNOP  macro  is  also 
provided  for  this  purpose.  Network  interrupts  can  be 
issued  by  means  of  the  NETINT  macro,  status  obtained  by 
means  of  NETSTAT  and  the  connection  closed  by  means  of 
NETCLOSE. 

Most  macros  expand  into  code  which  calls  subroutines  of 
the  same  name  as  the  macro.  Each  subroutine  is 
associated  with  an  appropriate  parameter  list  and 
generates  one  or  more  calls  to  the  NET  package. 

The  arrival  of  interrupt  control  messages,  from  the  NCP, 
is  detected  Dy  an  interrupt  from  the  VMCOM  device  on  the 
virtual  machine.  A  process,  therefore,  which  wishes  to 
suspend  itself  awaiting  some  network  activity  can  issue 
a  CMS  WAIT  SVC  on  the  VHCOM  device  until  an  interrupt 
control  message  has  arrived.  A  NETWAIT  macro  is  provided 
for  this  purpose,  when  the  interrupt  arrives  and  control 
is  returned  from  NETWAIT,  the  process  can  then  issue  a 
N2TN0P  macro  and  act  cn  its  flaqs  accordingly.  An 
example  of  this  procedure,  together  with  the  use  of  most 
of  the  macros,  is  given  in  the  TELNET  process. 
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X  •  80  • 

OPEN/NOTOPEN 
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X '  40  * 

SEND/RECEIVE 

EQU 

X  *  20  * 

NETWORK  INTERRUPT 

EQU 

X  •  10  * 

LISTEN  ISSUED 

EQU 

X  1 08  • 

BUFFERS  LOADED 

EQU 

X  *  04  * 

LINK  CLOSED 

EQU 

X  *  02  * 

ENABLE  MATCHED 

EQU 

X*01  • 

NCP  DIED  OR  RESET  ISSUED 

Set  when  CPEN  or  OPENE  macro  successfully  issued 
Cleared  on  successful  close. 

Set  when  CPEN  or  OPENE  macro  issued  on  send  socket 
Set  when  enable  on  send  socket  issued 
C lea  led  on  successful  close. 

Set  on  receipt  on  network  interrupt 
Cleared  on  a  netstat  before  STA  issued. 

Set  on  receipt  on  a  LISTEN  interrupt 
Cleared  on  a  netstat  before  STA  issued. 

Set  on  receipt  of  a  Buffers  loaded/ready  interrupt 
Cleared  on  a  netread  before  RCV  issued 
Cleared  on  a  netwrite  before  SNC  issued 
Cleared  on  a  netstat  before  STA  issued. 

Set  on  receipt  of  a  socket  closed  interrupt 
Cleared  on  successful  net  close. 

Set  on  receipt  on  an  enabled  completed  interrupt 
Cleared  on  a  netopen. 

Set  on  receipt  of  an  NCP  dead  interrupt 
Not  reset. 

Fig.  15:  NET  Flag  Bits 
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4.3  The  Logger-Server 


The  NET  system  is  designed  to  operate  in  the  CKS 
environment  which  supports  a  single  user  process  only. 
When  more  than  one  user  process  is  required  to  be 
concurrently  active  in  a  virtual  machine,  as  in  the  case 
of  the  logger-server,  a  polling  or  scheduling  routine  is 
needed  and  che  high-level  NET  commands  cannot  be  used. 
One  reason  for  this  is  because  the  high-level  commands 
deny  access  to  the  interrupt  stack  maintained  by  NET  and 
for  multi-process  working  it  is  necessary  for  the 
polling  routine  to  associate  NET  interrupts  with  the 
separate  processes.  Father  than  complicate  the 
high-level  command  interface,  it  was  decided  to  use  the 
primitive  NET  commands  for  the  logger-server  system. 

The  logger- server  is  designed  to  be  interrupt  driven  by 
a  simple  polling  routine  which  activates  a  number  of 
processes  in  turn  '.d  suspends  itself  whenever  all 
outstanding  interrupts  have  been  serviced,  tour  devices 
can  raise  interrupts  on  the  logger-server  virtual 
machine  and  thus  cause  the  polling  sequence  to  be 
resumed.  These  are  the  VMCCM  device,  whose  interrupt 
signifies  the  receipt  of  an  interrupt  control  message 
from  the  NCP,  and  three  CF  virtual  terminals  whose 
in  errupts  indicated  the  presence  of  messages  for  their 
associated  remote  users.  Associated  with  each  process  is 
a  table  which  contains  sufficient  details  on  the  state 
of  the  process  to  enable  it  to  be  restarted  from  its 
current  suspension  point.  The  table  includes  copies  of 
the  program  status  word  (FSW),  all  General  purpose 
registers,  buffers.-  flags  and  pointers  (see  Fig.  16). 

The  poller  accesses  two  flags  in  each  table;  the  WAIT 
flag  and  the  STAPT  flag.  If  the  WAIT  flag  of  a  process 
is  set,  that  process  will  not  be  re-activated  during  the 
current  poll,  but  if  it  is  clear,  the  poller  will  set  it 
and  3st  the  state  of  the  STAPT  flag.  If  the  STAPT  flag 
is  clear,  the  poller  will  restore  all  registers  from  the 
table  and  re-activate  the  process  at  the  point  defined 
by  its  PS w ,  tut  if  it  is  set,  the  poller  will  clear  it 
and  activate  the  process  at  a  start  address  specified  by 
a  start  entry  in  the  table. 

Four  processes  are  supported  by  the  poller;  an  enabling 
process  and  three  CP  virtual  terminal  control  processes. 
The  control  processes  are  all  identical  in  function  and 
are  implemented  by  a  single  segment  of  re-entrant  code. 
An  interrupt  handler  is  implemented  which  recognizes  all 
interrupt^  on  the  virtual  machine  and  associates  each  of 
the  four  devices  with  ?  particular  process.  The  VrtCOK 
device  is  associated  with  the  enabling  routine  and  each 
of  the  CP  virtual  terminals  is  associated  with  one  of 
the  control  processes.  On  receipt  of  an  interrupt,  the 
interrupt  handler  examines  the  STAPT  flag  of  the 
associated  process  and  if  this  is  clea.  it  clears  the 
WAIT  flag.  If,  however,  the  STAFT  flag  is  set,  it 
ignores  the  interrupt.  Since  a  device  interrupt  will 
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Fig.  16:  LOGGER  Routine  Flags 
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also  re-start  the  poller,  if  it  is  suspended,  the 
process  which  services  the  device  will  eventually  be 
re-activated. 


In  the  case  of  VMCOM  interrupts,  which  signifies  the 
arrival  of  an  interrupt  control  message  from  the  NCP, 
the  enabling  routine  issues  a  NO?  command  to  NET 
followed  by  a  subroutine  call  to  an  interrupt  stack 
handler.  This  handler  analyzes  the  NET  interrupt  stack 
and  generates  from  it  separate  interrupt  stacks  for  each 
of  the  processes.  When  a  new  entry  for  a  particular 
process  is  received,  the  WAIT  flag  for  that  process  is 
cleared  and  its  INTERRUPT  STACK  flag  set. 


A  process  suspends  itself,  when  awaiting  network  or 
device  activity,  by  means  of  a  special  wait  subroutine 
(WEACK)  which  saves  all  process  registers  and  the 
current  P5W  in  the  appropriate  table  before  returning 
control  to  the  poller. 


On  first  becoming  established,  the  logger-server  calls 
an  initializing  subroutine  which  attempts  to  clcse  all 
connections  between  itself  and  the  network,  purge  all 
references  to  any  of  its  sockets  from  the  NCP,  and  log 
out  all  CP  virtual  terminals.  Follcwir.q  this,  the 
process  tables  are  initialized  and  the  WAIT  and  START 
flags  set  for  each  process  except  the  enabling  routine, 
for  which  only  the  START  flag  is  set.  Control  is  then 
passed  to  the  pcller. 

The  pcller  can  activate  only  the  enabling  routine  at 
this  time,  and  this  causes  an  enable  connect  (ENC) 
command  to  be  issued  to  NET  for  the  initial  connection 
socket  (ICS)  of  the  logger-server.  The  routine  then 
suspends  itself  by  means  of  the  WEACK  subroutine. 


When  a  network  user  completes  a  connection  to  the  ICS  of 
the  logger-server,  the  NCP  sends  an  appropriate 
interrupt  control  message.  This  causes  the  enabling 
routine  to  be  re-activated  by  the  mechanisms  outlined 
above.  On  re-activation,  this  routine  accepts  the 
request  for  connection  from  the  network  user  if  there  is 
at  least  one  CP  virtual  terminal  unassigned.  It  will 
issue  the  appropriate  NET  commands,  in  accordance  with 
the  Initial  Connection  Protocol  (ICP)  described  in 
Section  2.6,  to  establish  duplex  communications  between 
the  sockets  of  the  next  unassigned  CP  virtual  terminal 
process  and  the  network  user  process.  On  the  successful 
completion  of  this  protocol,  the  enabling  routine  clears 
the  WAIT  bit  associated  with  the  newly  assigned  control 
process,  issues  an  enable  connect  for  the  initial 
connection  socket,  and  suspends  itself,  ready  to  repeat 
the  cycle  of  events.  If  th^re 
unassigned,  the  enabling  routine 
connection,  and  then  issues  the 
followed  by  the  WBACK  subroutine 


is  no  control  process 
refuses  the  request  for 
enable  connect  command 
call . 
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She  newly  assigned  control  process  will,  in  its  turn,  be 
activated  by  the  poller  at  its  start  address  and  will 
commence  to  transfer  information  between  the  network 
user  process  and  the  CP  virtual  terminal  interface,  in 
accordance  with  the  TELNET  protocol  and  the  CP  terminal 
conventions.  Initially,  the  control  process  is  concerned 
with  the  logging  on  sequence,  the  verification  that  the 
required  virtual  machine  is  marked  for  network  use,  and 
the  mapping  of  a  network  password  to  the  local  ono. 
Subsequent  activity  is  concerned  with  the  actual  passage 
cf  messages  between  the  network  us°r  process  and  its 
local  virtual  machine;  the  translation  cf  characters,  as 
reguired,  between  ASCII  and  EBCDIC;  and  the 
interpretation  of  special  control  characters  such  as 
•break*,  ’reverse  break*  and  ’synchronize*. 


Whenever  networ 
process  suspen 
until  the  res 
period,  one  of 
and  thus  the 
process  and  th 
concurrently,  w 


k  or  device  responses  are 
ds  itself,  using  the  WBACK 
ponse  has  been  received. 

the  other  processes  can  be 
poller  is  able  to  support 
e  three  CP  virtual  terrain 
ithout  any  apparent  loss  in 


required,  the 
subroutine , 
During  this 
re-activated 
the  enabling 
al  processes 
response. 


The  system  is  implemented  in  three  program  segments; 
LOG MAIN ,  LOCDEV,  and  LOGST.  LOGMAIN  contains  a  small 
initializing  routine,  the  poller,  the  enabling  routine, 
the  interrupt  handler,  the  NET  interrupt  stack  handler 
and  various  subroutines  for  stack  analysis  and  character 
code  conversion.  LOGDEV  is  the  re-entrant  segment  which 
effects  the  three  CP  virtual  terminal  control  processes 
and  LOGST  is  the  main  initializing  routiine. 


The  logger- server  can  be  closed  down  by  issuing  to  its 
virtual  machine  an  ’external*  interrupt.  This  causes 
the  WAIT  flag  tc  be  cleared  for  all  processes  in  use  and 
the  DOWN  flag  to  be  set.  On  re-activation,  each  CP 
virtual  terminal  control  process  will  issue  a  *LOGGEH 


CLOSING  DOWN*  message  to  its 
its  network  connections, 
terminated,  the  logger- serve 

Error  recovery  is  directed 
the  network  as  a  whole,  for 
detected  in  CP  virtual  ter 
either  network  command  reje 
NET,  or  virtual  terminal  tr 
In  either  case,  the  recover 
not  attempted  but  the  virtua 
is  legged  off,  its  network 
its  process  table  re-initi 
integrity  of  the  other  pro 
network  user  is  informed  of 
of  his  connections  and  the 
process  are  recovered  for 
the  enabling  process  are 
only.  Certain  rejections  are 
of  an  initial  END  comman 
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network  user  and  then  close 
When  all  processes  have 
r  halts. 

at  maintaining  a  service  to 
as  long  as  possible.  Errors 
minal  centre!  processes  are 
ctions  by  the  NCP,  through 
ansmission  rejections  by  CP. 
y  of  the  failing  process  is 
1  machine  associated  with  it 
connections  are  closed,  and 
alized.  In  this  way,  the 
cesses  are  maintained,  the 
the  failure  by  the  closing 
facilities  of  the  tailing 
re-use.  Errors  detected  by 
network  command  rejections 
recoverable  as  in  the  case 
d  failing  because  of  an 


insufficient  allocation  from  the  network  user.  In  such 
cases  the  command  is  repeated,  at  a  reasonable 
frequency,  until  it  is  either  accepted  or  a  repeat,  count 
has  become  exhausted.  In  the  latter  situation,  the 
connection  is  then  closed.  Other  rejections  are  not 
recoverable,  as  in  the  case  of  an  enable  connect  command 
failing.  Under  these  circumstances,  the  logger-server  is 
shut  down  after  a  trace  flag  has  been  set,  indicating 
the  source  of  the  error,  and  a  core  dump  output  to  the 
line  printer.  This  procedure  is  also  followed  if  a 
•program'  interrupt  condition,  signifying  a  fault  in  the 
program  code,  is  signalled  by  CP. 

4.4  The  Network  Control  Program 

As  in  the  case  of  the  logger-server,  the  network  control 
program  (NCP)  is  designed  to  be  interrupt  driven  by  a 
simple  poller  which  supports  a  number  of  concurrent 
processes  in  the  NCP  virtual  machine.  An  outline,  in 
block  schematic  form,  of  the  inter-relationships  between 
these  processes  is  shewn  in  Fig.  17. 

Each  process  is  implemented  by  a  separate  segment  of 
code  and  is  identified  cn  the  diagram  by  its  segment 
name . 

Coeraunication  with  user  processes,  in  other  virtual 
machines,  is  through  the  VMCOM  interface  which  is 
described  in  Section  4.2.  Communication  with  the  IMP  is 
through  the  IMI  hardware  interface,  which  was  designed 
by  BRYAN  (Ref.  2)  and  is  described  in  Appendix  12. 

NCPINIT  performs  initialization  and  error  recovery  tasks 
and  NCFKAIN  contains  the  poller,  the  interrupt  handler 
and  various  subroutines  associated  with  accounting  and 
recording  activities.  Processes  are  re-activated 
according  to  the  state  of  flags  in  the  PORT  TABLE  wnich 
are  updated  by  other  processes  and  the  interrupt 
handler . 

NCFXFER  accepts  control  messages  from  the  VMCOM 
interface  and  interprets  them  in  accordance  with  the  NET 
to  NCP  control  message  protocol  (Fig.  9).  Depending 
upon  the  type  of  request  and  the  current  state  of  the  RV 
TAELE,  NCPXFER  adds  items  to  the*  IMP'S  QUEUE  for 
transmi ssion  over  the  network,  adjusts  entries  in  the  RV 
TABLE  and  issues  a  reply  to  the  user  process  via  the 
VMCOM  interface. 

NCFIHPO  is  concerned  solely  with  the  output  of  the  II  S 
QUEUE  to  the  network  and  the  associated  control  of  the 
IMP  hardware  interface.  A  facility  is  included  whereby 
this  output  can  be  channeled  directly  into  the  input 
buffers  of  NCFIMPI,  for  test  purposes  or  for  local  use 
when  the  IMP  is  not  available. 

NCPIMPI  processes  all  input  from  the  IMP  and  implements 
the  HCST-to-IMP  protocol.  The  HCST-to-HOST  protocol  is 
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IMP  HARDWAR  INTERFACE 


TO  USER  PROCESSES 

Fig.  17:  The  Network  Control  Progra 
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implemented  partly  by  NCPIMFI  and  partly  by  WCPXFER . 
Depending  upon  the  type  of  message  from  the  network  and 
the  current  state  of  the  RV  TABLE,  NCPIMPT  loads  buffers 
for  collection  by  local  user  processes,  sends  interrupt 
ccrtrcl  messages  over  the  VMCOM  interface,  adjusts 
entries  in  the  RV  TABLE  and  add  items  to  the  IMP'S  QUEUE 
in  reply  to  network  messaces. 

NCPMONIT  provides  facilities  whereby  entries  in  the  PV 
TABLE  can  be  inspected,  certain  network  commands 
generated,  NCP  status  monitored  and  the  system  cleanly 
closed  down. 

U.U.1  NCFMAIN 

The  polling  mechanism  of  NCPMAIN  is  similar  to  that  of 
the  logger-server.  Interrupts  received  from  external 
devices  are  flagged  in  a  PORT  TABLE  which  is  used  to 
determine  the  next  process  for  re-activation.  Each 
device  is  associated  with  a  process  through  an  entry  in 
this  table.  Entries  associate  the  input  channel  from  the 
IMP  with  NCPIMFI;  the  output  channel  to  the  IMP  with 
NCFIMPO;  the  VMCCM  interface  with  NCPXFFR;  and  the 
console  terminal  with  NCPMONIT.  No  entry  is  required 
for  the  output  portion  of  the  VMCOM  interface. 

Each  entry  in  the  PCPT  TABLE  has  the  format  shown  in 
Fig.  18  which  was  originally  designed  for  duplex 
devices. 

It  was  subsequently  found  more  convenient  to  implement 
simplex  entries  but  the  earlier  structure  was  retained. 
The  format  is  described  as  a  set  of  field  names,  each 
followed  by  its  field  byte  size  in  parentheses.  Two 
sets  of  flags  are  defined;  POLLING  FLAGS  which  are  used 
by  the  poller  tc  determine  whether  the  process  should  be 
reactivated,  and  if  so,  at  which  address;  and  DEVICE 
FLAGS  which  indicate  the  current  state  of  the  associated 
device.  The  significance  of  both  sets  of  flags  is  given 
in  Fig.  1°. 

Other  fields  contain  th^  start  address  of  the  process, 
save  areas  for  its  PSW  and  registers,  and  a  buffer 
address.  These  fields  are  duplicated,  in  each  entry,  to 
provide  facilities  for  both  input  and  output  channels. 
The  CMS  DEVICE  ADDRESS  and  DEVICE  ID  are  also  specified 
ir.  the  PORT  TABLE  entry. 

The  format  of  the  buffers  is  given  in  Fig.  20,  and 
provides  fields  for  a  variable  length  MAIN  BUFFER,  the 
current  CHANNEL  STATUS  WORD  (CSW)  of  the  device,  and 
workspace  for  the  process. 

On  receipt  of  an  interrupt  from  a  device,  the  interrupt 
handler  sets  the  associated  DEVICE  FLAGS,  copies  the  CSW 
to  the  appropriate  field  ir.  the  buffer,  and  clears  the 
WAIT  SET  bit  in  the  PCLLIFG  FLAGS,  The  MAIN  BUFFER  is 
used  by  the  device  for  any  input  or  output  transfers. 
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POLLING  FLAGS  (1) 

DEVICE  INPUT  ROUTINE  ADDRESS  (3) 

DEVICE  INPUT  ROUTINE  PSW  (8) 

DEVICE  INPUT  ROUTINE  REGISTERS  (64) 

INPUT  BUFFER  ADDRESS  (4) 

DEVICE  FLAGS  (1) 

DEVICE  OUTPUT  ROUTINE  ADDRESS  (3) 

DEVICE  OUTPUT  ROUTINE  PS«  (8) 

DEVICE  OUTPUT  ROUTINE  REGISTERS  (64) 

OUTPUT  BUFFER  ADDRESS  (4) 

SPARE  (2) 

DEVICE  ADDRESS  (2) 

DEVICE  ID  (4) 

Fig.  18:  PORT  TABLE  FORMAT 


POLLING  FLAGS 

BUFIN  EQU  X  *  80  *  INPUT  BUFFER  LOADED 

BUFOUT  ECU  X  *  40 ’  OUTPUT  BUFFER  LOADED 

STATIN  EQU  X’20»  INPUT  STATE  BUSY 

STATOUT  EQU  X'lC  OUTPUT  STATE  BUSY 
WA IT  SET  EQU  X'08'  WAIT  STATE  SET 

SN D SET  EQU  X*04*  SEND  STATE  _  NOT  RECEIVE 

DEVICE  FLAGS 

INPROG  EQU  X  *  80*  IN  PROGRESS  STATE 
DEVENl  EQU  X  ’  40  *  DEVICE  END 

UEX  EQU  X  *  20  *  UNIT  EXCEPTION 

UCHK  EQU  X*10*  UNIT  CHECK 

ATTN  EQU  X 1 0 8*  ATTENTION 

UNEXBIT  EQU  X'04*  UNEXPECTED  BITS 

Fig.  19:  Rolling  and  Device  Flags 


TN73-50-I  Cl 9) 


TN73-50-I (18) 


POINTER  TO  MAIN  BUFFER  (4) 
SIZE  OF  MAIN  EUFFER  (4) 
CHANNEL  STATUS  WORD  (4) 
WORKSPACE  (variable) 

MAIN  EUFFER  (variable) 


|TN'73-50-I(20)  | 


Fig.  20:  Input  and  Output  Buffer  Formats 


The  poller,  if  suspended  on  a  CMS  WATT,  is  restarted  on 
the  receipt  of  an  interrupt  and  re-act ivates  the  first 
process  whose  WAITSET  bit  is  clear.  The  re-activation 
is  either  at  the  start  address  of  the  process  or  at  its 
current  PSW  depending  upon  the  state  of  its  STATIN  or 
STATOUT  flags.  Additionally,  an  output  process  requires 
its  8UF0UT  flag  to  be  set  before  the  poller  re-activates 
it. 

After  servicing  the  data  buffer  and  any  current 
interrupts  associated  with  a  device,  the  process  saves 
its  registers  and  PSW  in  the  appropriate  fields  and 
returns  control  to  the  poller,  awaiting  further 
interrupts.  Process  activity  typically  includes  the 
initiation  of  further  transfers  over  the  device  channel 
and  the  setting  of  certain  POLLING  FLAGS  in  the  PORT 
TABLE  entries  of  other  processes. 

NCEMAIN  contains  a  subroutine  for  writing  accounting 
records  to  disk,  in  the  format  shown  in  Fig.  21. 

The  subroutine  is  called  by  NCPXFER  and  NCPIMPI  to  write 
a  record  each  time  any  connection  becomes  fully 
established  or  fully  closed.  The  records  are  completed 
frcm  the  appropriate  entry  in  the  PY  TABLE  and  include 
the  time  at  which  the  first  Request  for  Connection  (RFC) 
is  made;  the  tine  at  which  the  connection  became  fully 
established;  the  time  at  which  the  first  close  is 
received;  and  the  time  at  which  the  connection  became 
fully  closed.  Other  fields  in  the  record  contain  the 
total  number  of  messages  and  bits  issued  over  the 
connection;  the  local  USEFID;  the  identities  of  both 
sockets;  the  foreign  HOST  and  the  link  number.  Although 
charges  are  not  being  raised  against  network  users  it  is 
considered  desirable  that  sufficient  information  be 
recorded  to  allow  the  identification  of  all  users  and 
their  utilization  of  system  resources. 

Other  elements  contained  in  NCPMAIN  includes  a 
subroutine  for  writing  legging  records  to  disk  and  a 
HOSTS  WE  KNOW  table.  The  subroutine  is  used  for 
recording  any  unusual  events  or  error  conditions 
detected  by  the  NCP.  The  HOSTS  WE  KNOW  taole  is  used  to 
maintain  an  ®ntry  for  the  current,  status  and  link 
utilization  of  every  HOST  on  the  network. 

.4.2  NCPXFEP 

NCPXFER  consists  of  a  routine  to  read  messages  from  the 
VMCOM  interface  and  a  s^t  of  command  routines.  Each 
message  is  analyzed  and  interpreted  as  a  command  from 
NET  and  the  appropriate  command  routine  is  then  entered. 
These  routines  typically  generate,  refer  to,  and  modify 
entries  in  the  PV  TABLE;  add  network  messages  to  the 
TMP*s  QUEUE,  and  send  reply  messages  back  to  the 
requesting  local  process. 
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USERID  (8) 

DATE  WRITTEN  (8) 

FIRST  RFC  TIME  (8) 

CCMFLETED  CONNECTION  TIME  (8) 
FIRST  CLOSE  TIME  (8) 

COMPLETED  CLOSE  TIME  (8) 

ICC AL  SOCKET  (4) 

FOREIGN  SOCKET  (4) 

FOREIGN  HOST  <1) 

FOREIGN  LINK  (1) 

FV  TABLE  STATUS  (2) 

NUMBER  OF  MESSAGES  (4) 

NUHBEF  CF  EITS  (4) 


]~TN73-50-I  (21) 


Fig.  21:  Accounting  Record  Format 


USEFID  (8) _ 

LOCAL  ID  (3)  ) 

J.CCAL  TAG  (1) _ _  ) 

FOREIGN  HOST  ~0)  ) 

FOREIGN  ID  (3)  ) 

FOREIGN  TAG  (1)  _  ) 

LINK  (1) 

STATUS  (2) 

CONNECTION  EYTE  SIZE  (1) 

HEAD  OF  BUFFER  CHAIN  (3) 

TEST  BYT?  (1) 

TAIL  CF  BUFFER  CHAIN  (3) 

ADDRESS  OF  NEXT  RV  ENTRY  (4) 

MESSAGE  ALLOCATION  (2) 

MESSAGE  ALLOCATION  (2) 

MESSAGE  FOP  RETURN  (2) 

DATE  (8) 

TIME1  (8) 

TIME2  (8) 

NUMEEF  OF  MESSAGES  TRANSMITTED  OVER  CONNECTION  (4) 
NUMBER  OF  EITS  TRANSMITTED  OVER  CONNECTION  (4) 

BITS  FOR  RETURN  (4) 

Fig.  22:  PV  Table  Format 


TN73-50-I (22) 


ICC  AL  SOCKET  (4) 


FOREIGN  SOCKET  (5) 
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The  RV  TABLE  contains  an  entry  for  every  connection 
supported  by  the  NCP  and  the  format  for  each  entry  is 
shown  in  Fig.  22. 

Fields  are  provided  for  the  USERID  of  the  local  process; 
the  local  and  foreign  sockets;  the  link  umber  assigned 
to  the  connection;  the  connection  byte  size  and  the 
current  message  and  bit  allocations.  Accounting  fields 
contain  details  of  the  date;  the  time  of  connecting;  the 
time  of  closing  and  the  cumulative  nurber  of  messages 
and  bits  transmitted  over  the  connection.  The  STATUS 
field  holds  a  set  of  flags  (Fig.  14)  ,  describing  the 
current  state  of  the  connection  and  address  fields  point 
to  the  head  and  tail  of  a  buffer  chain  associated  with 
it  and  the  next  entry  in  the  table.  The  MESSAGES  FOR 
RETURN  and  BITS  FOR  RETURN  rields  are  used  to  determine 
when  a  new  allocate  command  should  be  issued  to  a 
foreign  NCP. 

RV  TABLE  entries  are  established  for  control 
connections,  on  links  zero,  to  all  HOSTs  in  the  HOSTS  WE 
KNOW  table,  during  the  initialization  phase.  This 
enables  a  common,  internal  procedure  to  be  adopted  for 
all  network  transmissions.  Any  message  for  output  to 
the  network,  including  KCST-to-HOST  control  messages,  is 
formatted  by  the  originating  routine  and  added  to  the 
chain  of  buffers  supported  by  the  appropriate  send 
connection  entry  in  the  RV  TABLE.  A  pointer  to  this  RV 
TABLE  entry  is  then  added  to  the  IMF'S  QUEUE,  unless  one 
already  exists.  UOST-to-IMP  messages  are  treated  as  a 
special  case  and  are  only  issued  during  initialization 
and  shutdown  by  NCPINIT.  NCPIMPO  uses  the  pointers  in 
the  IMP'S  QUEUE  to  access  the  RV  TABLE  entry  and  the 
associated  buffers  for  transmission,  controlling  flow 
over  the  connection  by  means  of  the  RFNM  AWAITED  flag. 

Messages  received  from  the  network  are  analyzed  by 
NCPIMPI  ,  and  all  IMf-to-HOST  and  HOST-to-HOST  messages 
are  trapped  and  acted  upon  directly  by  this  routine. 
Process -to-process  messages  are  stripped  of  their 
message  headers  and  added  to  the  buffer  chain  of  the 
appropriate  receive  connection  entry  in  the  RV  TABLrJ. 

The  CONNECT  and  LISTEN  command  routines  of  NCPXFER , 
after  validating  the  request,  examine  the  RV  TABLE  for  a 
cc nplemen ta ry  entry  set  by  NCPIMPI  from  the  netwuiK, 
and,  if  none  exists,  generate  a  new  one.  An  STR  or  RTS 
ccrtrol  message  will,  in  either  case,  be  added  to  the 
buffer  chain  of  the  appropriate  link  zero  send  entry, 
for  transmission  to  the  foreign  NCP.  When  a  LISTEN 
request  matches  a  foreign  STR  entry,  an  initial  ALL 
coctrol  message  is  also  added  to  the  same  buffer  chain. 
The  SEND  ccmmand  routine  examines  the  RV  TABLE  for  the 
appropriate  send  connection  entry  and,  after  ensuring 
that  there  is  sufficient  allocation,  adds  the 
interprocess  message  to  its  buffer  chain,  decrementing 
the  allocation  fields  accordingly.  The  RECEIVE  command 
routine,  after  having  found  the  appropriate  receive 
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connection  entry,  collects  the  next  buffer  from  the 
buffer  chain  and  passes  it  to  the  requesting  local 
process.  It  increments  the  MESSAGES  FOP  RETURN  and  BITS 
FOR  RETURN  fields  by  the  size  of  the  message  and  if 
either  value  exceeds  a  given  thresholds  limit,  it  chains 
an  AIL  control  message  to  the  associated  link  zero  send 
entry  buffer  chain  and  resets  the  return  fields. 

The  other  command  routines  follow  similar  sequences;  the 
CLOSE  routine  issues  a  CIS  control  messaqe  and  removes 
the  RV  TABLE  entry  if  the  foreign  CLS  has  already  been 
received;  the  ENABLE  CONNECT  and  ENABLE  LISTEN  routines 
generate  new  RV  TABLE  entries  without  issuing  network 
messages;  the  DISABLE  and  PURGE  routines  remove  entries 
without  network  messages;  the  INTERRUPT  routine  issues 
an  INS  or  INR  control  message;  and  the  STATUS  routine 
clears  certain  bits  in  the  STATUS  field  after  placing 
its  value,  together  with  the  system  status,  in  the  reply 
control  message  buffer. 

In  all  cases  the  command  routine  issues  a  reply  control 
message  to  the  requesting  local  process  and  returns 
control  to  the  calling  routine.  This  routine  returns 
control  to  the  poller,  with  its  W AITS ET  flag  clear  if 
there  are  further  messages  to  be  read,  cr  with  it  set  if 
the  last  message  has  been  analyzed. 


a. 4. 3  NCFIMPI 

This  process  accepts  and  anlyzes  input  information  from 
eitner  the  real  IMP  hardware  interface  or  from  an 
artificial  software  •IMP*.  NCPINIT  activates,  during  the 
initialization  phase,  either  the  hardware  device  control 
routines  in  both  NCPIMPO  and  NCPIMPI,  or  the 
corresponding  artificial  IMF  routines,  in  accordance 
with  a  load  time  parameter.  The  NCPIMP  artificial  IMP 
routine  passes  the  output  from  the  NCP  directly  to  the 
analysis  routine  of  NCPIMPI  via  an  internal  buffer.  This 
mode  of  operation  is  to  test  new  sections  of  the  NCP 
without  disturbing  the  rest  of  the  network. 

The  same  analysis  routine  is  used  in  either  case,  and 
separates  input  into  three  classes  of  messages; 
irregular  messages  of  the  IMP-to-HOST  PROTOCOL;  regular 
messages  on  link  zero  of  the  HCST-to-HCST  protocol;  and 
regular  messages  on  non-zero  links  which  are  part  of 
interorocess  tr ansmissions. 

Most  irregular  messages  are  logged,  by  means  of  a 
subroutine  in  NCPMAIN,  and  appropriate  flags  are 
adjusted  in  PV  TABLE  ENTRIES,  HOSTS  WE  KNOW  status 
fields,  and  system  status  words.  A  type  5  irregular 
message  (RFNM)  causes  the  RFNM  AWAITED  flag  to  be 
cleared  in  the  associated  RV  TABLE  entry  and  the  NCPIMPO 
routine  to  be  flagged  for  re-activation.  A  type  7 
(destination  IMF  or  HOST  dead)  causes  a  flag  to  be  set 
in  a  particular  entry  of  the  HOSTS  WE  KNOW  table,  the 
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KFNH  AWAITED  flag  to  be  cleared  in  an  RV  TABLE  entry 
and  a  logging  record  to  be  written  to  disk,  other 
irregular  messages  cause  similar  sequences  to  be 
followed. 


Host-to-Host  control  messages,  on  links  zero,  are 
interpreted  as  one  or  more  control  commands  and  cause 
the  appropriate  control  command  routine  to  be  entered. 
These  routines  perforin  similar  tasks  and  are 
complementary  to  the  command  routines  of  h'CPXFER.  The 
STB  and  RTS  control  command  routines,  after  validating 
tne  tormat  of  the  command,  examine  the  RV  TABLE  for  a 
matching  entry  set  by  NCPXFER  on  behalf  of  a  local 

PIOc™S'  and'  11  GOne  exists'  generate  a  new  one.  when 
an  SIR  matches  a  local  LISTEN  REQUEST,  an  initial  ALL 
control  message  is  added  to  the  buffer  chain  of  the 
appropriate  link  zero  send  entry  in  the  rv  TAELE.  When 

-NAM-  a"  ENAB1E  1ISTEN  0r  an  RTS  etches  an 

~NAELa  CONNECT,  «n  interrupt  control  message  is  sent. 

over  the  V21CCM  interface,  to  the  associated  process.  The 
CLS  routine  clears  the  RV  TA3LE  entry  if  a  CLOSE  command 
has  already  been  issued  by  the  local  process,  otherwxse 
it  chains  a  CLS  control  command  to  the  appropriate  link 
zero  entry  in  the  RV  TAELE  and  issues  an  interrupt 
control  messages  to  the  local  process.  INS  and  INR 
command  routines  issue  interrupt  control  messages  to  th» 
lccal  process;  the  GVE  routine  returns  the  required 
fraction  of  the  allocation  by  chaining  a  RET  control 
command  to  a  link  2ero  entry  in  the  RV  TABLE;  and  FST 
removes  all  RV  TABLE  entries  associated  with  the-  issuing 
NCP  and  warns  all  local  processes  involved  via  an 
interrupt  control  message.  Similar  sequences  are 
followed  by  the  other  command  routines. 


II  rsn0rS  areidetected  in  a  message  from  a  foreign  host, 
an  ERR  control  message  is  returned  to  that  host.  Errors 
that  may  occur  are: 


a’  AA9?1  °P  Cod€  er*couhtered  in  operations 
deblocking. 

b.  Short  parameter  space.  En<3  of  messaqe 

encountered  before  all  expected  parameters. 

c.  Bad  parameter  (s)  ,  e.g.,  two  receive  (send) 

sockets  in  a  RTS  (STR)  ,  link  number  not  KL<32, 
bad  socket  polarity  within  command. 

d.  Request  on  a  closed  (null)  socket.  A  request 
(other  than  RTS/STF)  was  made  for  a  non-existent 
socket . 

e.  Socket  (link)  not  connected.  A  request  which 
requires  a  connected  socket  (link),  (i.e.,  ALL, 
INR,  transmit)  was  made  for  an  existing  but  not 
connected  socket  (link). 

f.  Eyte  size  not  consistent. 
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•  RFC  for  your  socket  already  issued  by  me  (timing 
error)  . 

h.  RFC  on  an  existing  socket  pair. 

i.  RFC  on  a  closed  socket  pair. 

j.  Allocation  too  small  for  this  transmission. 

Only  the  first  five  errors  have  been  given  a  network 
defined  error  code.  Refer  to  Appendix  D  for  a 
description  cf  the  ERF  control  message. 

Regular  messages  on  non-zero  links  are  stripped  of  their 
message  headers  and  added  to  the  buffer  chain  of  the 
associated  receive  entry  in  the  RV  TABLE.  If  the  BUFFLD 
flag  (Fig.  14)  is  clear,  it  is  set  and  an  interrupt 
ccrtrol  message  sent  to  the  local  user  process. 

After  completing  all  activity  associated  with  the 
current  input  buffer,  NCFIMPI  issues  a  new  input 
transfer  order  to  the  IMP  interface  and  suspends  itself, 
to  await  further  interrupts,  by  returning  control  to  the 
poller. 

4.4.4  NCPIMPO 

NCPIMPO  accesses  buffers  indirectly  pointed  to  by 
entries  in  the  IMP’S  QUEUE  and  outputs  their  contents  to 
either  the  real  IMP  hardware  interface  or  the  artificial 
IMP  internal  buffer.  Only  messages  addressed  to  (and 
originated  by)  the  local  NCF  are  passed  by  the 
artificial  IMF,  since  when  operation  is  in  this  mode, 
all  foreign  HOSTs  are  flagged  as  being  dead  in  the  HOSTS 
WE  KNOW  table. 

For  each  entry  in  the  IMP'S  QUEUE,  the  P V  TABLE  entry  is 
accessed  and  if  the  connection  has  rot  been  closed  and 
the  RFNM  AWAITEE  flag  is  not  set,  the  next  buffer  in  the 
buffei  chain  is  output  to  the  IMP,  and  the  RFNM  AWAITED 
flai  set.  As  buffers  are  output,  the  routine  frees  the 
associated  storage  and  when  all  buffers  in  a  chain  have 
been  output  the  corresponding  pointer  in  the  IMP’S  QUEUE 
is  removed. 

When  a  connection  is  fully  closed,  the  closing  routine 
(NCPXFER  or  NCFIMPI)  frees  any  storage  associated  with 
the  buffers  in  the  buffer  chain,  removes  the  entry  from 
the  RV  TABLE  and  flags  the  pointer  in  the  IMP’S  QUEUE  as 
'closed'.  NCPIMPO,  on  detecting  such  v  pointer,  removes 
it  from  the  IMP 'S  QUEUE. 

After  initiating  a  transfer,  NCPIMPO  suspends  itself  by 
returning  control  to  the  poller  with  its  WAITSET  and 
BUFOUT  flags  set,  awaiting  reply  interrupts  from  the 
IMP.  On  re-activation,  after  completion  of  the  transfer, 
NCPIMPO  attempts  to  output  further  buffers,  until  either 
all  have  been  tranferred  or  only  buffers  associated  with 
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RFNM  AWAITED  flags  ace  left.  Under  these  circumstances, 
it  suspends  itself,  by  returning  control  to  the  poller 
with  its  W  AITC  rT  and  BUFOUT  flags  clear.  It  can  then 
cnly  be  re- act...  tated  by  NCPIMPI  or  NCPXFER  setting  its 
BUFOUT  flag.  This  occurs  when  NCPIMPI  clears  a  RFNM 
AWAITED  flag  in  the  RV  TABLE  as  a  result  of  a  network 
message,  or  when  NCPIMPI  or  NCPXFER  adds  a  new  entry  to 
the  IMP'S  QUEUE 

4.4.5  NCFMON IT 

The  NCP  virtual  machine  can  be  run  disconnected  from  its 
control  cnp-sle  which  is  the  normal  mode  of  operation 
employed.  ror  monitor  purposes,  however,  the  virtual 
machine  is  re-connected,  usually  to  a  visual  display- 
unit,  and  the  NCPMONIT  process  activated  by  means  of  an 
'externaj  interrupt.  This  interrupt  is  detected  by  a 
routine  in  NCPI NIT  which  cause  the  typing  of  a  monitor 
message  and  the  clearing  of  the  WAITSET  flag  in  the 
NCPMCNI T  entry  cf  the  PORT  TABLE, 

Once  activated  ,  NCPMONIT  attempts  to  read  and  obey 
ronitcr  commands  typed  on  the  console  keyboard  until  a 
PI-jIN  cummand  is  entered*  This  command  de-activates  the 
NCPMONIT  process  until  the  next  ‘external*  interrupt  is 
received. 

1?.  addition  to  EEGIN ,  commands  are  available  tc  perform 
the  following  functions: 

a.  Disconnect  the  console  from  the  NCP  virtual 
machine  and  obey  a  BEGIN  command  (DISC) . 

b.  Set  the  CRAIN  flag  in  the  system  status  word  to 
deny  any  further  requests  for  connection  (CRAIN). 
This  is  normally  issued  shortly  before  shutdown. 

c.  Issue  an  echo  network  control  command  to  a  named 
foreign  HOST,  await  the  echo  reply,  che  \  its 
validity  ana  type  an  appropriate  message  on  the 
console  (ECHO),  "his  is  useful  for  determining 
whether  the  NCP  or  a  rem: te  HOST  is  active  or  rot. 

d.  Output  to  the  console,  the  current  status  of  all 
HOSIS  in  the  HOSTS  WE  KNOW  table  (PHOST) . 

f.  Issue  a  NOP  network  control  command  to  all  HOSTS 
in  the  HOSTS  WE  KNOW  table  and  obey  a  DISC  MONITOR 
COMMAND  (NOP) .  This  is  useful  in  that  it  obtains, 
from  the  network  replies,  the  current  status  of 
all  HOSTS. 

g.  Issue  an  FST  network  control  comma? a  to  all  HOSTs 
in  the  HOSTS  WF  NOW  TABLE  AND  OBEi  A  DISC  monitor 
command  (RESET)  This  is  issued  whenever  the  NCP 
is  re-established  ^ttr  a  shutdown. 

h.  List,  either  on  the  console  or  to  a  named  disk 


fiie,  aix  the  entries  in  the  BV  TABLE  (BV)  • 

i.  List,  on  t he  console,  all  the  entries  in  the  RV 
T*5LE  associated  with  a  named  socket  (SOCKET). 

i.  Output  to,  either  the  console  cr  a  named  disk 
t.'.le,  a  record  of  the  current  utilization  of  the 
NCP  (STATCS) • 

k.  Shut  the  NCP  down  cleanly  by  closing  all  current 
connections,  notifying  all  local  users  and  warning 
the  IMP  (SHUTDOWN).  The  final  part  of  this  process 
is  performed  ty  NCFINIT. 

l.  List,  on  the  console,  all  the  entries  in  th°  RV 
TABLE  associated  with  a  named  local  virtOTl 
machine  (USER). 

4.4.6  NCPINIT  and  Error  Recovery 


NCPINIT  consisted  of  a  set  of  routines  which  are  called 
by  NCPMAIN  for  initialization,  by  NCPMONIT  for  shutdown, 
and  by  all  processes  for  error  recovery. 

The  initialization  routine  reads  and  analyzes  lead  time 
parameters  which  determine  whether  the  real  or 
artificial  ISP  routines  are  o  be  established  in  NCPIMPI 
and  NCPIHPO,  and  whether  or  not  NCPMONIT  is  to  be 
activated  at  lead  tine.  Additional  parameters  can  be 
•stacked*  in  the  console  input  buffer  by  this  routine, 
fer  later  interpretation,  by  NCPMONIT.  This  mechanism 
is  normally  used  to  issue  a  RESET  monitor  command  when 
the  system  f’~st  becomes  active. 


After  analysis  of  the  load  time  parameters,  the 
interrupt  handler  in  NCPMAIN  is  established  and  all 
control  link  entries  are  set  in  the  BV  TABLE.  Selection 
of  the  appropriate  device  control  routines  in  NCPIMPI 
and  NCPIHPO  is  then  made  and  if  the  artificial  IMP  has 
been  specified,  all  foreign  HOSTs  are  flagged  as  dead  in 
the  HOSTS  WE  KNOW  TABLE.  If  the  real  IMP  is  specified, 
the  hardware  interface  is  activated  and  HOST-to-IMP 
prctccol  NOP  messages  are  sent  to  the  IMP  until  a 
satisfactory  reply  has  been  received.  A  HOST-to-HOST 
PPCTOCOL  ECO  control  command  is  then  sent,  by  NCPINIT, 
to  itself,  and  when  this  is  received  correctly  the  IMP 
interface  is  considered  to  be  established. 


Before  returning  contrcl  to  NCPMAIN,  the  program 
interrupt  PSW  is  set  to  th°  address  of  the  error 
recovery  routine  in  NCPINIT  and  the  external  interrupt 
trap  to  the  address  of  the  external  interrupt  handler. 

When  an  external  interrupt  is  received,  the  routine  in 
NCPINIT  determines  whether  or  not  a  console  is  connected 
tc  the  NCP  virtual  mach*..e  and,  if  one  is  connected, 
activates  NCFMCNIT.  If  no  console  is  connected,  a 
SHUTDOWN  monitor  message  is  stacked  in  the  console  input 
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buffer  before  the  activation  of  NCPMONIT.  The  system 
can,  therefore,  be  closed  down  simply  by  sending  an 
external  interrupt  .to  the  disconnected  NCP  virtual 
machine. 

The  shutdown  routine  in  NCPINIT  issues  an  interrupt 
control  message  to  all  local  users,  a  HOST-to-IMP 
protocol  ‘HOST  going  down'  message  to  the  IMP,  and 
closes  the  hardware  interface.  It  then  clears  the 
interrupt  handler  and  returns  control  to  CMS  with  a 
return  code  set.  When  the  shutdown  is  a  direct  result  of 
a  SHUTDOWN  monitor  command,  al?  network  connections  are 
closed  by  NCPKOINT  in  the  normal  way,  and  control 
returned  to  CMS  with  a  return  code  of  zero. 

In  the  case  of  an  involuntary  crash,  caused  by  a  program 
interrupt  from  CP,  the  program  interrupt  PSW  is  set  to 
the  address  of  a  final  error  recovery  routine:  a  copy  of 
all  registers  and  core  storage  is  dumped  to  the  line 
printer;  the  event  logged;  and  a  clean  close  do«n 
attempted  by  transferring  control  to  the  shutdown 
routine  with  an  identifying  return  code  set.  If  a  second 
program  interrupt  occurs,  control  is  returned  directly 
to  CMS  with  a  different  return  code  set.  The  other 
processes  call  NCPINIT  whenever  they  detect  an 
irrecoverable  error  condition  by  deliberately  causing  a 
program  interrupt,  arter  logging  the  event. 

The  NCP  virtual  machine,  after  having  been  automatically 
established  by  CP,  executes  a  ‘profile*  of  CMS  commands 
by  means  of  the  EXEC  facility  (Section  3) .  These 
commands  cause  the  Network  Control  Program  to  be  loaded 
from  disk  and  to  be  entered  at  its  start  address.  On 
control  being  returned  to  CMS,  furtner  commands  in  the 
profile  cause  a  warning  message  to  be  sent  to  the  CP 
console  operator  and  either  the  re- loading  cf  the  NCP  or 
the  ‘logging  off*  of  its  virtual  machine  according  to 
the  value  of  the  return  code  and  the  number  of  times 
re-lcading  has  teen  attempted, 

U.5  The  Treatment  of  E::rors 

It  is  considered  that  the  major  requirement  of  error 
recovery  for  the  network  system  is  to  maintain  effective 
connections,  on  behalf  of  users,  for  as  long  as  possible 
and  to  notify  them  whenever  a  crash  is  imminent.  A 
secondary  requirement  is  to  record  those  events  which 
lead  up  to  a  crash,  in  order  that  remedial  action  can  be 
taken  in  future  versions  of  the  system. 

Three  classes  of  error  are  detected;  device  errors 
associated  with  the  IMP  and  VHCOM  interfaces;  system 
errors  caused  ty  faults  ir.  the  program  logic  or  the 
exhaustion  of  facilities;  ana  protocol  errors  in  the  use 
of  any  of  the  software  interfaces.  A  fourth  class  of 
errer,  outside  the  control  of  the  virtual  machine,  is 
concerned  with  real  machine  failures.  Detection  and 
recovery  procedures  for  this  class  are  the 
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responsibility  of  CP. 

I fl P  hardware  errors,  occurring  during  the  initialization 
phase,  result  in  an  identifying  tnessaqe  beinq  typed  on 
the  NCP  virtual  machine  console,  a  particular  return 
code  set  and  control  returned  to  CMS.  The  profile, 
controlling  the  NCP  virtual  machine,  attempts  to 
re-initialize  the  system  a  number  of  times  and  if  the 
failure  persists  notifies  the  CP  operator  so  that  the 
IMP  can  be  investigated. 

Device  errors  occurring  after  the  initialization  phase 
has  been  completed  invariably  cause  a  system  crash.  The 
type  of  error  is  then  recorded  in  the  NCP  disk  log  and 
the  crash  routine  in  NCPINIT  is  entered.  The  crash 
routine  attempts  to  issue  an  interrupt  control  message 
to  all  local  users  and  a  ’closing  down’  message  to  the 
IMP  after  sending  a  complete  core  dump  to  the  (virtual) 
line  printer.  Any  device  errors  detected  by  the  routine 
are  ignored. 

System  errors  (Fig.  23)  in  any  part  of  the  Network 
Control  Program  also  results  in  the  event  being  logged 
and  the  crash  routine  in  NCPINIT  entered. 

System  errors  are  caused  by  such  events  as  the  failure 
to  obtain  a  block  of  free  store  for  new  table  or  queue 
entries;  the  detection  of  an  inconsistent  entry  or 
structure  in  one  of  the  tables;  the  receipt  of  an 
interrupt  from  a  device  not  in  the  POFT  TABLE  and  the 
detection  by  CP  of  an  attempt  to  perform  an  illegal 
operation . 

Protocol  errors  in  the  use  of  the  software  interfaces 
(Fig.  24)  never  result  directly  in  a  system  crash. 

Most  IMP-to-HOBT  tnessaaes  are  logged  and  any  format 
errors  from  the  IMP  are  ignored.  Checks  are  carried  Out 
on  the  validity  of  all  requests  from  foreign  NCPs  and 
ar.y  inconsi  stencies  or  errors  in  format  are  logged  and 
an  appropriate  error  messane  despatched  to  the 
originator.  The  validity  of  all  requests  by  NET  is 
checked  and  the  status  field  in  the  reply  control 
message  set  accordingly  (Fig.  14).  The  NFT  routines 
tests  the  validity  of  requests  from  a  process  and 
replies  with  error  codes  as  previously  listed. 

4.6  Concluding  Remarks 

This  report  has  described  the  approach  adopted  by  one 
site  in  implementing  its  network  software.  Other  sites 
have  adopted  different  approaches  consistent  with  tneir 
own  local  requirements.  The  NCP  developed  by  WHITE 
(Ref.  2^)  for  the  IBM  ^60/75  is  accessed  from  a 
batch-mode  job  under  the  M VT  operating  system.  Some 
sites  directly  modified  their  operatinq  systems  in  order 
to  incorporate  the  network  facilities. 
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CODE 

ADD  INFO 

FEASCN 

CRASH 

0 

Header  and 

Code  11  (ERR)  message  detected 

12  bytes 

from  f orNCP  (NCPIMPI) 

No 

1 

Header 

Code  1  message  detected  from  IMP 
(NCPIMPI) 

No 

2 

Header 

Code  3  message  detected  from  IMP 
(NCPIMPI) 

No 

3 

Header 

Code  8  message  detected  from  IMP 
(NCPIMPI) 

No 

4 

Header 

Code  9  message  detected  from  IMP 
(NCPIMPI) 

No 

5 

Header 

we  get  a  reset  reply 

No 

6 

SIO  IMP  IN  INOPERABLE  (NCPIMPI) 

Yes 

7 

SIO  IMP  IN  BUSY  (NCPIMPI) 

Yes 

8 

UE  ON  CC=1  IMP  IN  (NCPIMPI) 

Yes 

9 

Other  error  CC=1  IMP  IN  (NCPIMPI) 

Yes 

10 

Unexpected  Bits  IMP  IN  (NCPIMPI) 

Yes 

1  1 

UE  IMP  IN  (NCPIMPI) 

Yes 

12 

Not  DE  on  IMP  IN  (NCPIMPI) 

Yes 

13 

Insufficient  free  store  (NCPIMPI) 

Yes 

14 

Our  IMP  dead  (NCPIMPI) 

500 

15 

IMPS  link  table  full  (NCPIMPI) 

No 

16 

NOP  From  NCP 

No 

17 

18 

19 

Header  and 

We  sent  error  message  to  NCP 

16  bytes 

(NCPIMPI) 

No 

20 

Header 

We  get  a  re.  -»t  (NCPIMPI) 

No 

21 

System  error  in  CLS  (NCPIMPI) 

Yes 

22 

Header 

New  host  sent  to  us 

No 

23 

Header 

FOR  IMP/HCST  DEAD  (NCPIMPI) 

No 

24 

Header 

NOP  from  IMP 

No 

25 

SIO  IMP  OUT  Inoperable  (NCPIMPO) 

Yes 

26 

SIO  IMF  OUT  Busy  (NCPIMPO) 

Yes 

27 

UE  ON  CC=1  IMPOUT  (NCPIMPO) 

Yes 

28 

Other  error  CC=1  IMPOUT  (NCPIMPO) 

Yes 

29 

Unexpected  bits  IMPOUT  (NCPIMPO) 

Yes 

30 

UE  IMP  OUT  IMPOUT  (NCPIMPO) 

Yes 

31 

Interrupt  Handler  error  NCPMAIN 

Yes 

32 

XX/XX/XX 

Date/time  up 

No 

3  3 

Card  reader  error  (NCPXFER) 

Yes 

34 

Insufficient  free  store  (NCPXFER) 

Yes 

35 

Software  Table  error  (NCPXFER) 

Yes 

Fig.  23:  NCP  Error  Codes 


PROCESS /NET 


Fig.  24:  Major  Interfaces  in  the  System 
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Subsequent  to  the  original  development  of  the  network 
software,  a  number  of  changes  have  been  made  to  the 
network.  New  HOSTs  have  been  connected,  bringing  the 
total  now  to  thirty-six,  and  a  terminal  IMP  (TIP)  has 
been  introduced  (ORNSTEIN,  Ref.  13)  to  allow  terminal 
users  without  a  HOST  to  access  the  network.  Some  changes 
have  been  implemented  in  the  HOST-to-IMP  protocol 
(McKENZIE,  Ref.  11)  and  proposals  made  for  a  different 
HOST-to-HOST  protocol  (WALDEN,  Ref.  19).  Further  work 
has  been  carried  out  on  the  process-to-process  protocols 
(CFOCKEE,  Ref.  7),  on  the  design  of  the  network 
(McQUILLAN,  Ref.  12),  and  on  its  performance  measurement 
(COLE.  Ref.  5) .  Future  development  and  utilization  has 
been  discussed  by  ROBERTS  (Ref.  16) . 

Seme  of  these  changes  necessitated  modifications  to  the 
N2E.  In  the  case  of  new  HOSTs,  this  simply  requires  the 
* dditici  of  new  entries  to  the  HOSTS  WE  KNOW  table,  but 
irctoco.1  changes  require  some  modifications  to  the 
routines  themselves.  It  is  believed  that  the 
develop  cent  of  the  NCP  in  a  virtual  machine  and  its 
modular  structure  has  assisted  the  modification  process. 
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Appendix  A 
IMP  Interface 


The  IMP  is  connected  to  the  36C  multiplexer  channel  via 
a  duplex  interface  unit.  The  360  BEAT  command  may  be 
issued  only  to  the  input  segment  of  the  controller 
(address  60;  and  the  360  WRITE  command  may  be  issued 
only  to  the  output  segment  of  the  controller  (address 
61)  . 

The  controller  will  not  allow  its  Host  Masher  Ready 
relay  to  close  unless  the  CONTPOL-ON  command  has  been 
issued.  This  relay  closure  is  tested  by  the  IMP  at  all 
times.  The  360  program  must  issue  a  CONTROL-ON  to 
initiate  IMF  operation  and  must  maintain  such  a  command 
at  all  times.  When  terminating  IMF  operation  the 
CCNT BOL-OFF  command  should  be  issued.  This  command 
renders  the  controller  inert  to  all  IM*>  service  requests 
and  no  "Attention”  interrupts  will  be  sent  to  the  360. 

The  CONTROL-CN  command  the  CCNTBOL-OFF  command  may  be 
issued  only  to  the  read  address.  The  NO-O"  TEST  I/O, 
and  HALT  I/O  commands  may  be  issued  to  eit  address. 
All  other  commands,  or  an  improper  combination,  will 
then  result  in  the  command  being  rejected  during  initial 
selection.  Unit  Check  (Bit.  6)  will  appear  in  the 
initial  statue. 

After  the  36C  program  has  issued  a  CCNTROL-ON  command 
the  controller  goes  into  a  ready  state.  This  condition 
will  allow  the  input  seament  to  receive  data  from  the 
IMP.  Should  the  IMP  send  a  message  to  the  input 
segment,  the  first  16  bits  are  shifted  ir.  If  no  READ 
command  had  teen  issued  by  the  360  prcaram  an 
"Attention”  interrupt  is  sent  to  the  360.  The  360 
program  is  expected  to  respond  by  issuing  a  READ 
command. 

The  status;  response  in  the  CSW  during  initial  selection 
may  take  the  following  format: 

a.  All  zero  for  AD ,  WRITE,  or  TIC,  indicating  that 
the  command  was  successfully  initiated. 

b.  Unit  Check,  indicating  an  improper  command.  The 
command  will  have  been  rejected. 

c.  Unit  Exception,  indicating  that  the  IMP  Master 
Ready  relay  is  not  closed. 

d.  Device  End/Channel  End  will  be  given  in  response 
tc  CONTROl-ON,  CONTRCL-OFF,  and  NO-OP.  This  is 
also  considered  as  final  status  for  these 
ccmma  nd  s. 

e.  Status  Modif ier/Contrcl  Unit  End/Busy  will  result 
if  the  controller  is  "Busy"  at  the  time  the 
command  is  issued. 


Pinal  Status  will  be  given  at  the  completion  of  all 
operations.  It  will  consist  of  Device  End/Channel  End 
(HE/CE)  for  both  READ  and  WRITE.  Certain  other 

conditions  may  te  indicated,  as  follows: 

a.  Unit  Exception  will  be  given  if  the  last  data 

transfer  in,  or  out,  was  interrupted  by  the  IMP 
dropping  its  Master  Ready  signal,  even 

momentarily.  Unit  Exception  indicates  that  the 
data  received,  or  sent,  may  be  in  error. 

b.  A  Device  End/Channel  End  will  be  given  in  response 
to  Halt  I/O  if  a  command  was  indeed  in  operation 
at  the  time  the  Halt  was  issued. 

c.  Final  status  may  include  an  Attention  Bit  along 
with  DE/CE.  This  indicates  that  a  subsequent  READ 
must  be  issued  to  obtain  data  already  within  the 
input  segment. 


55 


Appendix  B 

HOST-to-I MF  Messages 


A  HOST-to-IMP  message  consists  of  not  more  than  8096 
bits  of  information  of  which  the  first  32  bits  are  known 
as  the  'leader* . 


4  |  4  |  8  |  8  |  8  |  variable 

II  III 

FI  AG  £  |  MESSAGE  |  DESTINATION  |  LINK  |  NOT  |  DATA 

|  TYPE  |  HOST  INUKBEH | ASSIGNEDI 

< - 32-Pit  leader - >| 


Fig.  B.1:  HOST-to- IMT  Message  Format 


T h e  leader  is  always  present  and  defines  the  type  of 
message,  its  destination  and  the  link  number,  if  any, 
with  which  it  is  to  be  associated.  A  descriotion  of  each 
hOSl-to-IMP  message  type  follows: 

a.  Regular  Message  (Message  Type  9). 

Regular  messages  are  forwarded  through  the  network 
and  presented  to  a  destination  HOST,  specified  by 
the  DESTINATION  HOST  field  in  the  leader,  as  a 
regular  I MP-to-HOST  message.  Regular  messages  are 
the  medium  for  all  HOST-to-HOS?  communications, 
the  DATA  field  being  formatted  according  to  the 
HOST- to-HOST  conventions.  Having  issued  a  regular 
message  on  a  particular  link,  that  link  is  said  to 
be  'blocked'  and  further  messages  cannot  te  sent 
until  a  PFNM  or  other  '  u nblocking'  message 
has  been  received. 

b.  Error  in  leader  (Message  Type  1). 

If  the  NCF  receives  an  T M F-to -HOST  message  with  an 
invalid  leader,  it  can  respond  with  a  Type  1 
HOST-to-IMP  message  to  advise  the  IMP  of  the 
format  error. 

c.  HOST  Going  Down  (Message  Type  2). 

The  NCP  should  transmit  a  Type  2  HOST-to-IMP 
message  about  10  seconds  before  voluntarily 
closing  dcwn.  The  imp  would  then  mark  the  HOST 
dead  and  advise  the  rest  of  the  network 
accordingly.  The  10-second  delav  is  to  allow  time 
for  the  notification  to  reach  all  other  TMPs  in 
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the  network  and  for  messages  already  in  transit  to 
be  processed. 

d.  No  Operation  (Message  Type  4)  . 

The  IMP  always  discards  this  message  which  is 
intended  for  use  during  initialization.  A  number 
of  Type  4  HOST-to-IMP  messages  are  to  be  issued  by 
the  NCF,  on  re-act iviation  after  a  shutdown,  to 
advise  the  IMP  that  the  HOST  is  alive.  The  IMP 
will  then  relay  this  information  to  other  IMPs  in 
the  network. 

e.  Regular  Message  for  Discard  (Message  Type  5)  • 

This  message  has  all  the  properties  of  a  Type  0 
HOST-to-IHP  regular  message  except  that  it  is 
discarded  by  the  destination  IMP,  before  it 
reaches  the  destination  HOST,  and  a  Type  9 
IMP-to-HOST  message,  rather  than  EFNM ,  is  returned 
to  the  originating  HOST  to  unblock  the  link.  The 
message  can  be  used  for  test  purposes. 

f.  Error  not  in  Leader  (Message  Type  8) . 

If  the  N CP  receives  an  IMP-to-HOST  message  which 
has  a  valid  leader  but  is  otherwise  in  error  with 
regard  to  the  HOST-to-IMP  protocol,  it  can  respond 
with  a  Type  8  HOST-to-IMP  message.  The  NCF  might 
respond  with  such  a  message  upon  receiving  an 
IMP-to-HOST  message  of  excessive  length. 

g.  All  other  HOST-to-IMP  message  types  are  undefined. 
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Appendix  C 

IMP-to-HOST  Messages 


A  IME-to-HOST  message  consists  of  not  more  than  8096 
bits  of  information  of  which  the  first  32  bits  are  known 
as  the  ‘leader* . 


TN73-5G-I (Cl) 


4  |  U  }  8  |  8  |  8  |  variable 

till  I 

FLAGS  | MESS  AGE | SOURCE |  LINK  \  NOT  |  DATA 

|  TYPE  I  HOST  | NUMEFUi ASSIGNED) 

_ 1 _ 1 _ 1 _ 1 _ 1 _ •  •  •  - 

I 

< - 32-Bit  Leader - >| 


Fig,  C.1:  IMP-to-HCST  Message  Format 


The  leader  is  always  present  and  defines  the  type  of 
message,  its  source  and  link  number,  if  any,  with  which 
it  is  associated.  A  description  of  each  IMP-to-HOST 
message  type  follows: 

a.  Regular  Message  (Message  Type  0). 

Type  0  IMP-to-HOST  message,  received  by  a 
destination  HOST,  originates  as  Type  0  HOST-to-IMP 
messages  in  the  source  HOST,  All  fields  are 
preserved  except  that  what  originates  as  the 
destination  HOST  identifier  in  the  HOST-to-IMP 
leader  is  converted  to  the  source  HOST  identifier 
in  the  IME-to-HOST  leader. 

b.  Error  in  Leader  (Message  Type  1) . 

The  IMF  issues  a  7y|.p  1  IMP-to-HOST  message  on 
detecting  an  error  ir  the  leader  of  a  previous 
HOST-to-IMP  message.  With  the  exception  cf  the 
MESSAGE  TYPE  field,  no  significance  is  to  be 
placed  on  the  contents  of  the  Type  1  leader. 

c.  IMP  Going  Down  (Messace  Type  2). 

A  Type  2  IMP-to-HCST  message  is  issued  by  the  IMP 
about  5  to  10  seconds  before  it  voluntarily  closes 
down.  The  delay  is  to  allow  notit  cation  of  its 
impending  shut  down  to  propagate  throuah  the 
network  and  for  messages  already  in  transit  to  be 
processed.  With  the  exception  of  the  MESSAGE  TYPE 
field,  nc  significance  is  to  be  placed  on  the 
contents  cf  the  Type  2  leader. 
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u.  Blocked  Link  (Message  Type  3) . 

The  IMP  will  issue  a  Type  3  IMF-to-HOST  message 
whenever  the  NCP  attempts  to  transmit  a  regular 
HOST-to-IMP  message  on  a  blocked  link.  With  the 
exception  of  the  MESSAGE  TYPE  field  the  contents 
of  the  leader  will  be  identical  to  that  of  the 
discarded  HOST-to-IMP  message. 

e.  No  Operation  (Message  Type  4). 

The  NCP  is  to  discard  all  Type  4  messages  from  the 
IMP.  These  are  intended  for  use  during  the 
initialization  phase  only. 

f.  Ready  For  Next  Message  (Message  Type  5). 

This  message  is  used  to  notify  the  NCP  that  the 
first  packet  of  a  HOST-to-IMP  regular  message  has 
been  successfully  passed  *  destination  HOST 
and  that  the  link  associated  th  it  is  now 
unblocked.  The  link  is  identified  by  the  contents 
of  the  SOURCE  HOST  and  LINK  NUMBER  fields  in  the 
leader  of  the  Type  5  message. 

g.  Link  Table  Full  (Message  Type  6). 

The  IMP  is  capable  of  supporting  at  most  63  active 
transmit  and  63  active  receive  links  at  any  one 
time.  A  link  is  defined  to  be  active  if  tne  NCP 
has  issued  a  HOST-to-IMP  regular  message  (or  a 
Type  5  regular  message  for  discard)  over  the  link 
within  a  period  of  about  30  seconds.  If  the  NCP 
attempts  :.u  exceed  this  limit  the  IMP  will  respond 
with  a  Type  6  message  whose  leader  is  identical, 
with  the  exception  of  the  MESSAGE  TYPE  field,  to 
that  of  the  rejected  HOST-to-IMP  regular  message. 

h.  Destination  IMP  or  HOST  Dead  (Message  Type  7) . 

This  message  is  issued  by  the  IMP  if  the  NCP 
attempts  to  transmit  a  HOST-to-IMP  regular  message 
(or  a  Type  5  regular  message  for  discard)  to  a 
HOST  or  IMP  which  is  known  to  dead.  The  leader 
of  the  Type  7  message  is  identical,  with  the 
exception  of  the  MESSAGE  TYPE  field,  to  that  of 
the  rejected  HOST-to-IMP  regular  message. 
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i.  Error  not  in  Leader  (Message  Type  8)  . 

If  the  IMP  receives  a  HOST-to-IMP  message  which 
has  a  valid  leader  but  is  otherwise  in  error  with 
regard  to  the  HOST-to-IMP  protocol,  it  will 
respond  with  a  Type  8  IMP-to-HOST  message.  This 
message  has  a  leader  which  is  identical,  with  the 
exception  of  the  MESSAGE  TYPE  field,  to  that  of 
the  rejected  HOST-to-IMP  regular  message.  The  IMP, 
for  example,  will  issue  a  Type  8  message  on 
receiving  a  HOST-to-IMP  message  cf  excessive 
length. 

j.  Incomplete  Transmission  (Message  Type  9) 

A  Type  9  IMP-to-HCS'"  message  is  issued  to  notify 
the  NCP  that  the  last  HOST-to-IMP  message  sent 
over  a  particular  link  failed  in  transmission  for 
seme  reason.  The  failure  can  be  attributed  to  the 
unaccounted  loss  cf  some  portion  cf  the  message; 
the  less  of  the  associated  RFNM;  a  message  of 
excessive  length  or  an  excessive  time  required  for 
re-assembly  at  its  destination.  A  Type  9 

IMP-to-HOST  message  is  always  returned  in  response 
a  Type  5  HOST-to-IMP  message,  instead  of  a  PFNM . 
Its  receipt  unblocks  the  link  and  its  leader  is 
identical,  with  the  exception  of  the  MESSAGE  TYPE 
field,  to  that  of  the  rejected  H<jST-to-IMP 
message. 

k •  All  other  IMP-to-HOST  messa.a  types  are  undefined. 
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Append!  D 

The  HOST-to-r:,r  Protocol 


i 


All  HOST-to-HOST  communications  are  effected  by  regular 
HOST-to-IMP  and  IMP-to-HCST  messages.  Control  messages 
are  associated  with  link  0  and  interprocess  messages 
with  ncn-zero  links.  The  format  of  all  HOST-to-HOST 
messages  is  as  shown  in  Fig.  5. 

Link  Assignments: 

link  numbers  are  assigned  as  follows: 


a.  Link  0 

b.  Links  2-71 

c.  Links  1,  72-190 

d.  Link  191 

e.  Links  192-255 


-  Control  Link. 

-  Intei process  Communications. 
Pcserved. 

-  Network  Keasurement. 

-  Private  Experimental  Use. 


Central  Messages: 


Messages  sent  over  the  control  link  have  the  same  format 
as  other  HOST-te-HOST  messages.  The  connection  byte  size 
is  to  be  8  bits  and  the  number  cl  bytes  is  not  to  exceed 
12C.  Control  messages  are  always  tc  consist  of  an 
integral  number  of  control  commands. 


Control  Commands: 


Each  control  command  begins  with  an  8-bit  *  op-code' , 
which  drfines  the  function  of  the  command,  Toiloved  by  a 
set,  in  some  cases  null,  of  prrameteis  which  qualifies 
the  function.  A  description  of  each  control  command 
follows : 


a.  NOP  -  No  Operation. 


I  NOP  | 

I _ I 

The  NOP  Command  can  be  issued  at  any  time  and  is  to 
be  discarded  by  the  receiving  NCP,  It  is  useful  for 
formatting  control  messages  and  for  determining,  from 
the  I NP-to- HOST  reply,  whether  a  foreign  NCP  is 
active  or  not. 
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.  .ct ion,  Receiver  to  Sender 


b.  RTS  -  Request  foi  Cv?.* 


i  T  T  i 

|  RTS  |  receive  socket  |  send  socket  |  link  | 

The  RTS  command  is  used  to  establish  a  connection  and 
is  sent  from  the  HOST  containing  the  receive  socket 
to  the  HOST  containing  the  send  socket.  The  link 
number  to  be  used  by  the  interprocess  connection  is 
to  be  in  the  range  k-  71  and  is  assigned  by  the 
issuing  NCP.  There  is  no  prescribed  lifetime  for  an 
RTS  command  which  can  te  queued  by  the  receiving  NCP 
for  an  arbitrarily  long  period  of  time.  The  command 
cculd  be  cancelled  by  either  NCP  issuing  a  C1,S 
(section  C. 3, d)  and  the  connection  is  established 
when  either  the  RTS  matches  a  previously  issued  STR 
(section  C.3.c)  or  when  an  STP  is  subsequently  issued 
which  matches  the  PTS, 

c.  STR  -  Request  for  Connection,  Sender  to  Receiver. 


I  I  I  I  i 

I  STR  1  send  socket  |  receive  socket  |  size  | 

The  STR  command  is  used  to  establish  a  connection  and 
is  sent  from  the  HOST  containing  the  send  socket  to 
the  HOST  containing  the  receive  socket.  The 
connection  byte  size  is  to  be  in  the  range  1-255  and 
is  assigned  by  the  issuing  NCP.  There  is  no 
prescribed  lifetime  for  an  STR  command  which  can  be 
queued  by  the  receiving  NCP  for  an  arbitrarily  long 
period  of  time.  The  command  can  be  cancelled  by 
either  NCP  issuing  a  CIS  (section  C.3.d)  and  the 
connection  is  established  when  either  the  STR  matches 
a  previously  issued  PTS  (section  C.3.b)  or  when  an 
PTS  is  subsequently  issued  which  matches  the  STR. 

d,  CLS  -  Close. 


|  CLS  |  my  socket  |  your  socket  | 

I _ 1 _ 1 _ _ I 

The  CLS  command  is  used  to  terminate  a  connection  or 
tc  cancel  a  request  for  connection.  The  'my  socket' 
field  contains  the  socket  local  to  the  issuinq  NCP 
and  the  'your  socket'  field  contains  the  socket  local 
tc  the  receiving  NCP.  There  is  nc  prescribed 
lifetime  for  a  CLS  command  but  it  is  required  that  an 
NCP  reply  with  a  matching  CLS  'as  quickly  as 
possible'  in  order  that  the  sockets  can  released 

ter  further  assignments 
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e.  AIL  -  Allocate 


III  I  I 

|  ALL  |  link  |  message  space  |  bit  space  | 

I _ 1. _ 1 _ i _ _ I 

The  ALL  command  is  sent  iLcm  a  receiving  NCP  to  a 
sending  NCP  to  increase  the  allocation  counters  of 
the  sending  NCP.  Allocate  commands  can  be  issued  at 
any  time  while  a  connection  is  fully  established. 
Interprocess  messages  can  only  be  transmitted  over  a 
connection  within  the  specified  allocation. 

f.  GVB  -  Give  Back. 


<11  I  I 

|  GVB  |  link  |  message  fraction  |  bit  fraction  | 

I _ i _ 1 _ . _ L _ 1 

This  command  i:.  lent  from  a  receiving  NCP  to  a 
sending  NCF  to  i  guest  that  the  sending  NCP  return 
all  or  part  of  its  message  and  bit  allocation  for  the 
connection.  Ihe  fraction  fields  specify  what  portion, 
in  128ths,  of  each  allocation  is  to  be  returned.  The 
command  can  only  be  issued  while  a  connection  is 
fully  established  and  the  recipient  NCP  is  to  reply 
with  a  PET  command  (section  C.  3.  g)  . 

PET  -  Return  Allocation. 


|  RET  |  link  J  message  space  |  bit  space  ) 

i _ 1 _ I _ L _ 1 _ I 

This  command  is  sent  from  a  sending  NCP  to  a 
receiving  NCP  either  voluntarily  or  in  response  to  a 
GVB  command  (section  C,3.f).  The  command  can  only  be 
issu9d  while  a  connection  is  fully  established. 

h,  INR  *  Interrupt  by  Receiver. 


{  INF  |  link  | 

I _ i _ I 

INR  command  can  be  sent  from  a  receiving  NCP  to  a 
sending  NCP  when  the  receiving  process  wishes  to 
interrupt  the  sending  process.  ?h<=>  command  can  only 
be  issued  while  a  connection  is  fully  established. 
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i.  INS 


Interrupt  by  Sender 


I  INS  |  link  | 

I _ J _ I 

The  INS  command  can  be  sent  from  a  sending  NCP  to  a 
receiving  NCP  when  the  sending  process  wishes  to 
interrupt  the  receiving  process.  The  command  can  only 
be  issued  while  a  connection  is  fully  established, 

j.  ECO  -  Echo  Request. 


I  ECO  |  data  | 

I _ 1 _ I 


The  ECO  command  is  used  only  for  test  purposes.  An 
NCP  could  issue  an  ECC  command  at  anv  time  to  another 


NCP  and  would  expect  tc 
(section  C.3.k)  in  reply, 
bit  pattern  convenient  to 
pattern  is  to  be  repeated 
ERP  command. 


receive  an  EFP  command 
The  data  field  can  be  any 
the  sending  NCP  and  the 
in  the  data  field  of  the 


k .  EFP  -  Echo  Reply. 


!  i  I 

|  ERP  (  data  | 

I _ i _ I 

The  EPP  command  is  to  be  issued  by  an  NCP  whenever  it 
receives  an  echo  request  (section  C.l.i).  The  data 

field  of  the  ERP  command  is  to  be  identical  to  the 
data  field  of  the  incoming  ECP  command. 

1.  EPR  -  Error  Detected. 


\ 


Ar  NCP  is  permitted  tc  issue  an  EFC  command  whenever 
it  detectes  a  H0S7-to- HOST  protocol  error  by  another 
NCP.  The  cole  field  specifies  the  tyoe  of  error  and 
the  data  field  provides  additional  information  about 
the  error.  The  following  codes  have  been  defined: 
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Code  0  -  Undefined.  An  error  for  which  nc  code  exists 


has  been  detected. 

The 

data  field  is  to 

be 

formatted  according 
originating  NCP. 

to 

the 

requirements  of 

the 

Code  1  -  Illegal  Op-code. 

An 

illegal  op-code 

has 

been  detected  in  a  control  message.  The  data  field 
is  to  contain  a  copy  of  the  command  in  error. 

Code  2  -  Short  Parameter  Space.  The  end  of  a  control 
message  has  been  encountered  before  ill  the 
required  parameters  have  been  found.  The  data 
field  is  to  contain  a  copy  of  the  command  in 
error . 

Code  3  -  Ead  Parameters.  Incorrect  parameters  have 

been  found  in  a  control  command.  The  data  field  is 
to  contain  a  copy  of  the  command  in  error. 

Code  4  -  Request  on  a  Non-Existent  Socket.  A  request, 
other  than  an  F.TS  or  STR,  has  been  received 
associated  with  a  link  or  socket  for  which  no 
request  fer  connection  has  been  issued  in  either 
direction.  The  data  field  is  to  contain  a  copy  of 
the  command  in  error. 

Code  5  -  Socket  or  Link  Not  Connected.  A  request, 

other  than  an  RTS  or  STR,  has  been  received  for  a 
connection  rot  fully  established  cr  for  a  link  not 
yet  assigned.  The  data  field  is  to  contain  a  copy 
of  the  command  in  error. 

m.  PST  -  Reset. 


I  I 
|  PST  | 


The  RST  command  is  used  by  on<=>  NCP  to  inform  another 
that  all  information  concerning  existing  connections 
between  the  two  should  fce  purged  from  the  tables  of 
the  NCP  receiving  the  RST.  The  sendino  NCP  can 
expect  to  receive  an  RRP  command  (section  C.3.n)  in 
reply. 

n.  RRP  -  Reset  Feply. 


|  RRP  | 


This  command  is  to  be  issued  by  an  NCP  in  reply  to  an 
RST  command  (section  C.3.m). 

o.  All  oth^r  op-codes  are  undefined. 
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Appendix  E 

CP  Support  for  a  Virtual  Terminal  Device 


Modifications  to  CP  have  been  made  to  support  a 
•software  terminal9,  i.e»,  one  driven  by  a  virtual 
machine  rather  than  by  a  real  device  such  as  a  2741.  CP 
performs,  via  software,  functions  usually  done  by  SIO’s 
to  a  real  terminal  device.  The  purpose  is  to  provide 
terminal-like  access  to  CP  for  users  wishing  to  log  on 
to  the  system  through  the  APPA  network.  The  LOGGER 
virtual  machine  runs  a  program  which  interfaces  between 
the  network  and  CP  virtual  terminals. 

Two  new  multiplexer  devices  (TYPNCPT  and  TYPNCPC)  have 
been  defined  to  support  virtual  terminals.  An  NCP 
terminal  block  (NCPT)  has  been  added  to  the  chain  of 
real  device  blocks  ( MRDEFLC  Ks)  and  a  user  logged  on  to 
such  a  terminal  appears  to  CP  like  any  ether  user  except 
at  the  console  (PDCONS  and  WR7C0NS)  level  or  lover. 
PCCONS  and  WPTCONS  detect  I/O  to  NCPTs  and  create  CCW 
packages  identical  to  those  made  up  for  I0529s. 

yirtual  terminal  devices  (NCFD*s)  ar^  defined,  throuah 
the  directory,  as  part  of  the  iCGGEF  virtual  machine. 
I/O  instructions  from  the  LOGGER  to  an  NCPD  are 
interpreted  according  to  a  protocol  for  communicating 
with  an  NCPT.  Initially,  an  addressed  NCPD  must  be 
associated  with  an  available  NCPT  so  that  a  user  may  log 
on.  Sub senuen tl y ,  information  is  transferred  between  the 
NCPD  and  an  NCPT  to  satisfy  CP  real  and  write 
operations. 

Initial  connection  is  estallishea  oy  a  HIO  from  the 
LOGGER  virtual  machine  to  one  of  its  available  NCP 
devices.  This  HIO  causes  CP  to  search  for  a  free  NCP 
terminal  (in  the  chain  of  "RDEBLCKs)  and  + o  establish  a 
connection  between  the  two.  All  subsequent  I/O 
operations  concern  the  transfer  o*  data  accross  this 
connection  until  the  link  is  broken. 

A  connection  once  established  may  be  broken  in  one  of 
two  ways:  by  t  he  user  typing  ‘LOGO9  cr  by  th«  LOGGER 
virtual  machine  issuing  a  TIC  to  its  NCP  device.  The 
second  ca se  is  analogous  to  a  user  turning  power  off  on 
a  27u1  terminal,  and  may  occur  because  the  LOGGER 
crashed  and  came  back  up,  or  because  a  network  link  was 
closed.  The  first  case  If  detected  in  the  same  way  as  a 
logoff  from  any  other  terminal  device  is  detected.  The 
LOGGER  is  informed  of  the  broken  connection  by  means  of 
a  unit  check  in  his  CSW. 

A  read- type  command  from  the  virtual  machine  to  its  NCP 
device  is  issued  to  pick  up  data  from  C?  writes.  The 
data  in  CP's  write  buffer  is  moved  into  the  area 
beginning  at  the  virtual  machine*s  read  address,  and  the 
read  commar.c  is  terminated  with  C£  and  PE.  NCP  support 
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follows  the  protocol  for  a  1052  in  that  a  'locked 
keyboard'  system  is  maintained.  Thus,  the  virtual 
machine  controlling  NCP  devices  should  always  keep  a 
read-type  command  active  on  these  devices. 

When  CP  puts  up  a  read  to  an  NCF  terminal,  the  virtual 
machine  is  signalled  to  send  data  by  a  unit  exception 
on  the  NCP  device.  This  sequence  is  analogous  to  the 
write  circle  C/read  circle  D  needed  to  unlock  the 
keyboard  of  a  2741.  Cr  receipt  of  a  unit  exception,  the 
LOGGER  virtual  machine  should  respond  by  issuing  a 
write-type  command  to  the  NCF  device. 


The  I/O  operations  defined  for  an  NCP  device,  and  the 
responses  to  them,  are  as  follows. 

TIO:  used  as  a  power  off  signal  when  a  network  connection 
has  been  closed. 

CC  =  0  means  a  user  was  on  and  has  been  logged  off. 

CC=1  means  no  connection  existed. 

HIO:  used  as  an  attention  signal.  If  no  connection  between 
the  addressed  NCP  device  and  an  NCP  terminal  exists, 
this  routine  will  attempt  to  find  an  available  NCP 
terminal  and  establish  a  connection.  In  this  case, 

CC  =  1  means  a  connection  was  established. 

CC=2  means  there  is  no  available  NCP  terminal. 

If  a  connection  exists,  HIO  acts  like  an  attention 
interrupt. 

CC=C  means  an  ATTN  has  been  simulated,  and  an  interrupt 
is  pending. 

CC= 1  means  ATTN  has  been  simulated,  but  the  NCP  device 
had  no  active  command,  so  no  interrupt  will  be 
recei ved . 

SIO:  used  to  transmit  and  rc.cieve  data.  Only  read  and  write 
are  defined. 

CC=0  means  OK,  I/O  started. 

CC= 1  means  CfW  stored.  Meaningful  bits  are  busy, 
attention  (means  warning  is  coming,  and  a  read 
should  be  issued) ,  unit  check  (means  no  link  to  an 
NCPm  exists) ,  unit  exception  (means  CP  wants  to 
read,  and  user  should  write  to  his  NCFC) ,  and 
program  check  (means  a  read  was  issued  when  a 
write  was  required,  or  vice  versa) . 

CC-.'  means  device  busy. 

Interrupts  received  after  a  successful  SIO  may  be: 
CE*DE:  successful  termination 

CE+IE+UE:  occurs  only  or.  a  read-tvpe  ccmmand,  and 
CF-*-CE*UF*SU:  means  that  CP  is  asking  *or  a  userid.  It 
allows  the  LCGGEP  to  monitor  his  user’s  logon 
synchronously  with  CP. 

ATTN:  occurs  asynchronously  when  CP  is  waiting  for  the 
LCGGE?  to  send  data,  i.e.  when  his  keyboard  is 
unlocked.  It  means  a  warning-type  message  wants 
to  blast  throuoh. 

CE+CE  +  'JC:  means  user  has  looged  off. 


Appendix  F 


CP  Virtual  Machine  Communications  Facility 


Purpose : 


The  VMCGM  facility  allows  the  virtual 
to  another  virtual  user  logged  on  to 
receive  data  transmitted  fro®  another 


user  to  send  data 
the  CP  system,  or 
virtual  user. 


Fcrjra  t : 

The  VMCOM  diagnose  instruction  is  defined  as  follows: 


I  83 

I _ 

1 


I  81  I  F2  |  CODE 

i - J - 1 _ 

15  16  IT 


I 

I 


Pointer  to  a  Control  Block 
net  used 

(  x  'GO  50  *)  used  to  designate  the  VMCOM  request 

^2Htrol  Block: 

Bile  Data 

C  USERID  (8) 

8  Request  flag  (1) 

9  Data  buffer  address  (3) 

12  Length  of  data  buffer  (2) 

14  Number  data  bytes  read  (2) 


where : 

PI 

F2 

CODE  - 


Sgjguest  Flag 


Inscription 


x»  01  * 
x  *  02  * 
x '  03 ' 
x'  C4 ' 
x  *  05  * 
x  *  06  * 
x  *  07  * 

x  •  30 ' 


fcnte  data  to  user’s  stack  (wait) 

Read  data  from  own  data  stack 
Purge  data  from  own  data  stack  (all) 
Purge  data  sent  to  particular  USERID 
Test  for  any  data  in  own  data  stack 
Test  for  data  sent  to  particular  USERID 
write  data  to  user's  stack  (no  wait) 

Lost  message  flag 
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n  sa^e : 


The  receiver  of  a  data  write  will  receive  a  device  end 
interrupt  on  virtual  device  x'fd'  when  some  data  has 
been  placed  on  his  data  stack.  The  receiver  should  then 
initiate  a  read  request  to  get  the  data  into  his  virtual 
machine.  For  the  writer  of  data,  there  is  a  limit  of  one 
data  transfer  between  a  virtual  machine  pair.  If  this 
limit  is  exceeded,  a  condition  code  2  will  be  reflected 
on  the  data  write  attempt,  and  the  receiver's  control 
block  will  have  the  request  flag  byte  set  to 
bll ' 1 xxxxxxx'  to  indicate  data  lost.  Cata  writes  will 
write  the  whole  data  buffer  out,  data  reads  will  read  up 
to  the  buffer  length  and  then  indicate  data  buffer 
overflow.  Null  writes  and  null  reads  are  allowed  to 
communicate  interrupts  between  virtual  users.  A  write 
with  no  wait  will  be  allowed  for  class  4C'  users  only. 

End ing  Conditions: 

Cc ndi ticn  Code  rescript ion 

Successful  completion 
Unsuccessful  completion 
Control  Block  not  full  word  aligned 
Control  Block  not  within  virtual  cor*3 
Bata  buffer  not  within  virtual  core 
Invalid  request  flag  specified 
Cata  buffer  >  4096  bytes 
hot  a  class  'C'  user,  request  invalid 
Lata  buffer  overflow  cn  read  request. 
Unprocessed  data  in  receiver's  data  stack 
(Jeer  not  on  system 

Unable  to  reflect  interrupt  to  receiver 
No  data  in  stack  on  read  request 


CCO 
C  Cl 


CC  2 
CC  3 
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Purpose 


Appendix  G 
The  NET  Routine 


Tc  communicate  with  the  NCP  to  issue  NCP  control 
commands  or  to  receive  a  message  which  has  been  buffered 
by  the  NCP 

Calling  Sequence; 

The  user  makes  a  subroutine  call  of  the  form: 


LA 

1 , NETPLIST 

L 

1  5  ,= A  (NET) 

EALR 

i  1 5 

LTR 

15,15 

BNZ 

1 5  f ERROR 

where  NETPLIST  is  of  the  form; 


CI4 

•Control  Code* 

XL  3 

•My  ID* 

XL  1 

•  My  Tag • 

XL1 

•  For  Host  * 

XL  3 

•  For  ID' 

XL! 

•For  Tag* 

XL1 

•  Flag' 

H 

'  Eit  count • 

AL4 

(Euffer  Address) 

F 

•  Status  Reply* 

F 

•  Eits  Left* 

H 

'Messages  Left' 

X 

'  Byte  Size' 

X 

' Spare  1 

AL4 

(Address  of  interrupt  stack) 

and  where 

Control  Codes  are; 

CON 

Connect 

LIS 

LisCen 

SN  D 

S  end 

KCV 

Recei ve 

CLS 

Close 

STA 

Request  Status  of  Socket 

INT 

Sent  interrupt 

NOP 

retrrns  net  status.  Useful 

ENC 

Enable  connect 

ENL 

Enable  listen 

DI  S 

Disable 

PUR 

Purge 

71 


A  send  buffer  must  contain  an  80-byte  header  f allowed  by 
up  to  1000  bytes  of  data.  The  NET  routine  . ill  use  the 
6C-byte  header  to  build  an  NCP  contr'l  message. 
Similarly,  r.  receive  buffer  must  be  1080  bytes  long. 
The  first  80  bytes  will  be  used  for  the  NCP  control 
message  and  the  rest  of  the  buffer  will  be  used  to  store 
the  text  of  any  message  which  was  held  by  the  NCP. 

Before  any  call  to  NET  is  made,  the  interrupt  stack 
pointer  should  be  cleared.  On  return  from  a  call  to  NET 
the  interrupt  stack  pointer  should  be  checked.  If  it  is 
zero,  no  interrupts  were  received.  A  non-zerc  pointer 
indicates  that  an  interrupt  was  received  and  the 
interrupt  stack  control  block  should  be  analyzed  and 
then  returned  to  free  storage.  The  Interrupt  Stack 
Control  Block  is  shown  in  Fig.  G. 1  and  the  Interrupt 
Codes  are  listed  in  Fiq«  G.2. 

Errors: 

Control  is  always  returned  from  the  NET  package  with  a 
code  in  general  purpose  register  15.  The  return  codes 
are  as  follows: 

0  Command  accepted  by  NCP.  Tag  status  given  in  reply. 

1  Command  rejected  by  NCE.  Tag  status  given  in  reply 
indicates  reason  for  rejection. 

2  NETPLIST  control  code  invalid. 

Status  reply  not  significant. 

3  VMCOJ1  failure, 

4  Nothing  there  (NCP  Special  Case) . 

5  Unexpected  message  received  by  NET  . 

8  NCP  error. 

Reply  does  net  match  socket  number  issued. 

6  VWCOM  read  error. 

Q  VMCOM  send  error. 

10  Nc  more  free  store  for  NET. 

11  NCP  just  died. 

12  Zero  bit  count. 


jrN73-50-I(G.l) 


! 

CODE  |  NEXT  IN  CHAIN 

ICC A I  OCKET 

“  J 

FHOST  | 

_ _ _ i 

I 

FOR  J 
SOCKET  | 

_ - _ 1 

STATUS 


Fig.  G.  1:  Interrupt  Stack  Control  Block 


''OCKET 


SPARE 


CODE 

0 

1 

2 

3 

4 

5 

6 
7 


WEANING 
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Interrupt  received.  Could  be  SND  or  RCV  socket. 
Status  must  be  issued  to  clear  this  bit. 


His  listen  issued  on  our  SND  socket. 

After  the  connection  has  been  completed . 

Receive  buffer  now  loaded  after  issuing  our 
listen  (His  connect  implied)  . 

His  CIS  received  before  we  have  issued  ours. 

Enabled  connect  matched  by  his  connect. 

Enabled  listen  matched  by  his  connect. 

NCP  Died. 


Foreign  NCP  Reset  (RST  received). 


Fig,  G.2:  Interrupt  Codes 
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Appendix  H 
NET  User  Macros 


General : 

A  link  block  must  be  defined  for  each  link  required* 
This  block  contains  local  and  foreign  socket  numbers 
together  with  status  and  flag  areas.  The  NETPLIST  macro 
is  a  DSECT  which  specifies  the  format.  Link  blocks  are 
defined  by  NETSOCK  or  NETSOCKV  macros,  and  refer  either 
to  send  or  receive  links.  The  user’s  network  id  must  be 
obtained  with  the  NETID  macro  which  obtains  a  user 
number  and  places  it  in  the  appropriate  portion  of  the 
socket  number. 

The  link  roust  then  be  activated  via  a  NETOPEN  macro. 

Transfers  are  achieved  via  NETREAD  and  NETNRITE  macros 
and  the  link  may  be  closed  via  the  NETCLOSE  macro. 

Link  status  may  be  obtained  using  NETSTAT  and  network 
interrupts  may  be  sent  using  NETINT.  NETNOP  obtains  the 
current  flag  state  without  accessing  the  NC^5. 

Macros : 


NETSCCK  (GA ,€B, SC) 


Defines  a  link  block.  It  reguires  a  label  which  is 
used  by  all  other  macros  to  identify  the  link.  It 
has  three  parameters: 

SA  -  a  1-byte  hex  value  of  the  local  tag 

SB  -  a  1-byte  hex  value  of  the  foreign  host 

SC  -  a  4-fcyte  hex  value  of  the  foreign  socket 


NETSOCKV  <SA,SB,SC) 

Is  an  alternative  to  NETSOCK.  It  also  defines  a  link 
block  and  requires  a  label  for  link  identification 
purposes.  It  has  three  parameters. 


&  A  -  a  label  for  the  1-byte  local  tag 

SB  -  a  label  for  the  1-byte  foreign  host 

SC  -  a  label  for  the  4-byte  foreign  socket 

Before  using  the  link  specified  by  NETSOCKV  values 
must  be  moved  into  the  locations  named  by  GA,  SB  and 
SC .  For  exairpie: 

MV  I  T  A G  #  X  ’  0  1  ’ 

MV  I  FHOST, X ’ OA ’ 

MV  C  FSOC (4) , =X  *  00000001  * 


LINK  1 


NETSOCKV  TAG ,FKCST, FSOC 


The  following  macros  require  the  link  block  lauel  as  the 
first  parameter  {S A ) : 


NETID 

lilTCPEN 

NETOFENE 

RETREAD 

NETWRITE 


NET  ST  Vi' 
NE7  . 

NETN  .P 

NETCIOSE 

NETENA 

NETDTSA 


Obtains  user's  network  id  and  places  it  in 
the  link  block 

Assigns  a  link  and  establishes  the 
connection. 

Used  after  a  NETENA  to  open  a  connection 

Transfers  into  the  specified  buffers  any 
outstanding  data  in  the  link  (max  10CC 
bytes) 

Transfers  from  specified  buffers  to  network, 
(max  10C0  bytes) 

Obtains  network  status  of  link 

Issues  appropriate  network  interrupt 

Obtains  current  interrupt  state 

Closes  the  c(  nnectioi 

Defi  es  a  local  socket  for  which  a  foreign 
host  can  initiate  a  connection 

Releases  a  local  socket  which  was  enabled 


NETPUF.SE  Causes  the  entry  in  the  NCP  RV  table  to  be 
deleted  for  a  closed  connection  which  has 
not  been  closed  by  the  foreign  host 

The  NETREAD  and  NETWPITE  macros  have  two  other 
parameters.  SB  is  the  address  of  a  full  word  containing 
the  buffer  address.  SC  is  the  address  of  a  full  word 
containing  the  tit  count. 


A.  V  ETNA  IT  may  te  issued  to  wait  for  an 
When  the  wait  completes,  <i  NE'„  NCF  may  be 
current  interrupt  (s)  *ili  be  placed  in 
star  k. 


NC?  interrupt, 
issued  and  the 
the  interrupt 


Fet  .irn  Codes: 

eturn  codes  in  OPR 15  are: 

0  -  Operation  completed  satisfactorily  -  Status  field 
si^nifican* 

1  -  Operation  denied  by  network.  Status  field 

significant 

2  -  User  made  logical  error.  Status  not  significant 

System  Pailure.  Status  n^t  significant 
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Appendix  I 
The  MLCTST  Program 


turp^se : 

This  program  is  used  to  issue  CCW's  to  the  HLC/IMP.  The 
program  has  a  one-character  command  language.  It  is 
useful  to  issue  these  commands  on  one  line  separated  by 
the  logical  break  character  (#)  , 

Reguests : 

I  (INPUT)  -  To  se+  the  current  I/O  device  to  the  IMP'S 
input  device 

0  (OUTPUT)  -  To  set  the  current  I/O  device  to  the  IMP'S 
output  device. 

N  (ON)  -  To  turn  the  IMP  on.  This  request  must  be  issued 
on  the  IMP'S  input  device. 

F  (OFF)  -  To  turn  the  IMP  cff.  This  request  must  also  be 
issued  cn  the  IMP'S  input  device. 

F  (READ)  -  To  issue  a  read  SIO .  If  a  read  is  already 
outstanding,  a  2  (busy)  results.  When  the  read 

completes,  the  data  read  will  be  in  an  input  buffer 
which  can  be  displayed  or  dumped.  A  read  on  the 
output  device  causes  a  CC=1  with  the  CSW  stored 
indicating  a  program  check. 

W  (WRITE)  -  To  issue  a  write  SIO.  The  data  written  is 

set  up  to  be  a  IMP  NOP  (a  4-byte  leader  only)  .  A 

write  on  the  input  device  causes  a  CC  =  1  with  the  CSW 
stored  indicating  a  program  check. 

H  (HIO)  -  To  issue  a  HIC  instr  :tion  to  tHe  current 

dev  ice. 

T  (TIO)  -  To  issue  a  TIO  instruction  to  ue  current 

device 

X  (NOP)  -  To  issue  a  NOP  CCW  to  the  current  device. 

V  (invalid)  -  To  issue  an  invalid  CCW  operation  code  to 
the  current  device. 

D  (DISPLAY)  _  To  dump  the  incut  buffer  which  contains  the 
data  last  read.  CP  is  used  to  display  the  storage 
a  rea . 

P  (PAUSE)  -  To  issue  a  CMS  WAIT  on  the  input  dpvice  to 
wait  for  an  interrupt. 

C  (UUIT)  -  To  leave  the  MLCTST  program. 
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Appendix  J 
The  TRYNET  Program 


Purpose : 

To  test  an  NCP  using  the  NET  routine. 
Segues ts: 


CON 

Is 

fh 

fs 

bs 

LIS 

Is 

fh 

fs 

bs 

SND 

Is 

message 

RCV 

Is 

I  NT 

Is 

CLS 

Is 

STA 

Is 

ENC 

Is 

ENL 

Is 

DIS 

Is 

PUR 

Is 

END 

where : 

-s  -  is  a  local  socket  (8  hex  digits) 

fh  -  is  a  foreign  host  (2  hex  digits) 

fs  -  is  a  foreign  socket  (8  hex  digits) 

bs  -  is  the  byte  size  for  the  connection  (2  hex  digits) 

message  -  is  a  string  of  characters  to  be  sent  over  the 
connection 
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Requests;  are  issued  from  the  terminal  tc  perform  a  basic 
NCP  function.  For  each  request  issued,  the  PV  table 
entry  is  returned  if  one  exists.  The  second  two  status 

bytes  are  printed  indicating  the  status  of  the  socket 
connection. 


Whenever  an  interrupt  is  received,  a  line  is  printed 
giving  the  type  of  interrupt,  when  an  RCV  is  issued,  the 
message  received,  if  any,  is  also  printed.  If  an  NCP 
communications  message  is  lost  (VKCOM  interrupt  lost), 
this  fact  is  also  printed.  The  user  shculd  then  issue  a 
status  on  each  of  the  active  sockets  to  determine  the 
interrupt  which  was  lost. 


Appendix  K 

The  TELNET  LCGGER/5  ERVEF 


I CP  Conngct ion : 

The  TELNET  LOGCER/SERVER  follows  the  ICP  protocol  for 
naking  a  pair  cf  connections.  The  LOGGER  is  initially 
enabled  for  a  connection  on  socket  X'OOOOOOOI'.  When  an 
RFC  is  received  for  this  socket  a  pair  cf  sockets  will 
be  chosen  for  the  TELNET  connections.  If  the  maximum 
number  of  TELNET  users  which  can  be  served  are  active, 
the  initial  connection  is  refused.  Current  y,  three 
TELNET  users  can  be  served. 

TELNET  LOGGER: 

After  the  ICP  connections  have  been  setup,  the  LOGGER 
expects  a  TELNET  data  type  code,  a  string  of  network 
ASCII  characters,  or  a  null  line  (just  CR-LF)  to 
indicate  whether  its  operation  should  te  in  ASCII  or  in 
EBCDIC  character  codes,  ASCII  is  assumed  unless  the 
first  bype  received  is  the  TELNET  EBCDIC  data  type  code 
(X *  A 2)  •  When  something  has  been  received,  the  message: 

Lincoln  Laboratory  CP/CMS  Online 

will  be  transmitted  by  the  1CGGEF.  For  example,  if 
ASCII  operation  is  desired  a  null  line  (just  CR-LF) 
transmitted  on  the  send  socket  will  cause  the  welcoming 
ressage  to  be  sent  in  ASCII.  The  CP  login  procedure  can 
then  begin.  If  communications  is  desired  to  be  carried 
on  with  EBCDIC  character  codes,  the  first  byte 
transmitted  should  be  the  TELNET  data  type  code  for 
EBCDIC  (X • A  2 • ) •  Thereafter  all  communications  will  be  in 
the  code  originally  used. 

The  CP  login  procedure  expects  the  user  to  enter: 

LOGIN  userid 

where  the  userid  specifies  the  desired  virtual  machine. 
C?  then  replies  with: 

ENTER  PASSWORD: 

followed  by  the  EBCDIC  code  for  byp  .ss  fX'2U«)  which  is 
mapped  into  the  TELNET  code  h ide- your- i nput . 

The  user  should  then  ente  a  password.  Passwords 
entered  from  the  network  may  be  different  frcm  those 
entered  from  a  local  terminal.  The  LOGGER  maps  network 
passwords  into  a  corresponding  CP  password.  Thus, 
access  to  an  account  can  only  be  made  from  the  network 
if  a  network  password,  together  with  a  CP  password  and 
userid,  is  entered  into  a  file  which  is  read  by  the 
LOGGER.  If  a  userid  entered  from  the  network  is  not  in 
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the  LOGGER  FILE  (or  if  the  network  password  does  not 
match  the  one  included  in  the  file  for  the  specified 
userid)  the  10GGER  passes  an  invalid  userid  (or 
password)  to  CP.  The  CP  response  for  an  invalid  userid 
or  password  is  then  sent  to  the  network  user. 

After  a  password  is  received  by  CP,  CP  transmits  the 
EBCDIC  code  for  restore  (X*14®)  which  is  mapped  into  the 
TELNET  control  noecho. 

TELNET  SERVER: 


Since  the  CP/CMS  sys*«m  operates  with  EFCDIC  codes, 
ASCII  codes  must  Le  trai. slated  into  EBCDIC  before  being 
sent  to  a  virtual  machine.  Figure  K.1  gives  the  ASCII 
codes  and  their  EBCDIC  mapping.  When  the  ASCII  sequence 
CR-LF  is  received,  it  is  mapped  into  the  EBCDIC  cede  NL. 
whenever  the  TELNET  control  NOP  is  included  in  an  input 
string,  it  is  mapped  into  an  EBCDIC  idle  (X' 17* )  and 
then  removed  f r  :m  the  string.  Thus,  if  TELNET  NOP  codes 
are  included  between  a  CR  and  LF,  they  are  removed 
before  the  CR-LF  is  mapped  into  the  EBCDIC  NL . 

The  TELNET  control  hide-your-input  is  mapDed  into  the 
EECCIC  code  for  bypass  (X*2U»)  and  the  TELNET  control 
echo  is  mapped  into  the  EBCDIC  control  for  restore 
(X’14') .  If  the  TELNET  control  echo  is  received,  the 
SERVER  should  send  the  control  noechc  but  this  feature 
has  not  yet  beer,  implemented.  Instead,  the  TELNET 
control  echo  is  mapped  into  the  EECDIC  code  X*23*.  If 
the  TELNET  break  is  received,  it  is  interpreted  as  an 
attention  signal  and  the  appropriate  action  is  taken  by 
CP  or  CNS. 

CP/CMS  is  a  line  at  a  time  system  and  expects  all  input 
to  consist  of  lines  ending  with  a  NL  code.  Characters 
received  are  buffered  until  the  newline  code  is 
received . 

Since  C  P/CM  S  is  also  a  half  duplex  system,  characters 
are  only  examined  when  the  system  is  expecting  input. 
If  the  system  is  not  expectiriq  incut,  a  network 
interrupt  is  required  to  cause  the  SERVER  to  process 
received  characters.  Or  receipt  of  a  network  interrupt, 
characters  received  before  the  TELNET  data  nark  is 
received  are  examined  and  discarded,  except  that  if  a 
TELNET  break  code  is  found,  the  appropriate  CP/CfiS 
interrupt  action  is  stimulated. 

On  output,  EECDIC  codes  are  mapped  into  network  ASCII  if 
a  mapping  exists;  otherwise,  the  codes  are  mapped  into 
the  TELNET  control  NOP.  A  NL  code  is  mapped  into  CR-LF. 
The  EECCIC  code  for  oypass  maps  into  the  TELNFT  control 
hide-your-input  and  the  EBCDIC  code  for  restore  maps 
into  the  TELNET  control  noecho.  Also,  the  code  X'23* 
«ra  fs  into  the  TELNET  control  echo  and  the  code 
mafs  into  the  TELNET  control  break. 
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Since  CP/CHS  is  a  line  at  a  time,  half  duplex  system  the 
TELNET  control  break  is  transmitted  as  an  end  of  message 
signal  and  also  as  an  input  prompt  code.  If  characters 
were  output  without  a  FI,  the  break,  as  an  end  of 
message  code,  indicates  to  the  user  TELNET  operating  on 
a  line  at  a  time  mode  that  the  characters  previously 
transmitted  should  be  printed  without  waiting  for  the 
end  of  line  sequence.  If  the  user  TELNET  is  also 
operating  in  a  half  duplex  mode,  the  break  as  an  input 
prompt  indicates  that  the  system  is  ready  for  input. 


If  input  had  been  anticipated  and  sent  by  a  full  duplex 
user  TLi.NE I ,  the  TELNET  SEFYER  will  have  that  input 
available  for  immediate  processing.  Thus,  in  the  case 
cf  a  full  duplex  user  TELNET  the  break  as  a  prompt 
should  be  ignored. 


Though  CP/CMS  operates  in  a  half  duplex  mode,  it 
supports  half  duplex  terminals  with  the  reverse  break 
feature  allowing  the  system  to  abort  an  input  mode  in 
order  to  transmit  a  priority  output  message.  In  this 
situation,  the  TELNET  SERVES  transmits  a  TELNET  SYNC.  A 
half  duplex  user  TELNET  should  interpret  this  by 
aborting  the  input  mode,  i.e.,  revoking  a  previous 
TELNET  break  which  was  interpreted  as  an  input  prompt. 

Nc  codes  in  the  output  character  stream  can  cause  the 
TELNET  data  mark  to  be  transmitted. 


IfSCUT: 


When  a  user  logs  out  from  his  virtual  machine,  CP  passes 
\he  equivalent  cf  a  line  disconnect  to  the  LOGGER.  Che 
LOGGER  then  closes  the  TELNET  send  and  receive  sockets. 
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25 

26 
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ASCII 

ASCII 

ASCII 

SYMBOLS 

EBCDIC 

EBCDIC 

DEC 

OCT 

HEX 

HEX 

DEC 

32 

40 

(20) 

SP 

(4C) 

64 

33 

41 

(21) 

j 

(5A) 

90 

34 

42 

(22) 

ii 

<7F) 

127 

35 

43 

l23) 

# 

(7E) 

123 

36 

44 

(24) 

$ 

(5B) 

91 

37 

45 

(25) 

% 

(6C) 

108 

38 

46 

(26) 

6 

(50) 

80 

39 

47 

(27) 

» 

(7D) 

124 

40 

50 

(28) 

( 

(«  0 

77 

41 

51 

(29) 

) 

<5C) 

93 

42 

52 

( 2A ) 

* 

(5C) 

92 

43 

53 

( 28) 

♦ 

(4  E) 

78 

44 

54 

(2C) 

t 
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45 

55 

(2D) 

- 

r 

96 

46 

56 

(22) 

• 

(4  ) 

75 

47 

57 

(2F) 

/ 

(61) 

97 

48 

60 

(30) 

0 

(FO) 

240 

49 

61 

(31) 

1 

(FI) 

241 

50 

62 

(32) 

2 

(F2) 

242 

51 

63 

(23) 

3 

(F  3) 

243 

52 

64 

(34) 

4 

(FU) 

244 

53 

65 

(35) 

5 

(F  5) 

245 

54 

66 

(36) 

6 

(F6) 

246 

55 

67 

(37) 

7 

(F7) 

247 

56 

70 

(38) 

e 

(F  8) 

248 

57 

71 

(39) 

9 

<P9) 

249 

58 

72 

(3A) 

: 

(7A) 

122 

59 

73 

(30 ) 

t 

(5  E) 

94 

60 

74 

(3C) 

< 

(4C) 

76 

6 1 

75 

(3D) 

= 

(7E) 
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62 

76 

(3E) 

> 
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1  10 

63 

77 

(3F) 

7 

(6F) 
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Fig.  K. 1:  LOGGER  ASCII/EBCDIC  Code  Mapping 
(Cent  inued) 
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Fig.  K.1:  LOGGFP  ASCII/EBCDIC  Codp  Mapping 
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Fig.  K.  1:  LOGC-FR  ASCII/EECDIC  Code  Happing 
(Continued) 


85 


Appendix  l 
The  User  TELNET 


££££££§: 

To  access  another  terminal-oriented  system  on  the  AFPA 
network. 

Fcr mat : 


TELNET  host  <tag>  EESUHE  EBCDIC  HALFLUP 
1  OPEN  ASCII  FULLDUP 

host  -  either  the  hexadecimal  code  for  a  foreign 
network  service  site  or  a  standard  mnemonic  for  a 
foreign  site.  See  Figure  1, 

tag  -  the  identifier  for  the  local  connections  to  the 
network.  The  taq  is  used  together  with  the 
address  of  the  virtual  machine  descriptor  table 
(UTABLE)  to  form  lccal  socket  numbers  which  are 
used  in  the  network  protocol. 

PESUfiE  used  to  reactivate  communications  with  a 
foreign  site  after  having  previously  left  the 
TELNET  command  leaving  the  connections  open. 

EBCEIC  -  to  communicate  with  EBCDIC  codes.  The  default 
is  network  ASCII. 

HALFDUP  -  to  operate  under  a  half  duplex  protocol,  i.e. 
with  a  locked  keyboard. 

The  EECEIC  HALFDUP  the  protocol  assumes  that  the 
TELNET  break  code  (circle  C)  will  be  received  to 
indicate  when  the  keyboard  should  be  locked  for 
input. 


In  ASCII  HALFDUP  the  keyboard  will  lock  after  a 
lin»  of  input  and  will  unlock  after  one  or  more 
lines  have  been  received  for  output.  An  external 
interrupt  will  also  unlock  a  locked  keyboard. 

The  default  is  full  duplex  where  the  keyboard  is 
alwasy  unlocked  for  input.  a  null  line  is 

^q!?if:l.!°.t!,np?rarily  locK  the  keyboard  in  order 

*  '-C  C  1 V  £  Output. 
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Usage: 


A  number  of  hosts  on  the  ARP  A  network  provide  TELNET 
service.  A  Network  Virtual  Terminal  (NVT)  has  been 
specified  so  that  using  sites  can  write  one  TELNET 
program  which  maps  a  local  terminal  into  the  NVT  to 
access  any  serving  site  on  the  network.  Once 
communication  has  been  established  between  a  using  site 
and  a  serving  site,  kayed  input  is  sent  to  the  serving 
system  and  output  froi  the  serving  site,  when  received, 
is  typed  on  the  local  terminal. 

The  NVT  protocol  requires  that  the  keyboard  be  capable 
of  entering  all  of  the  128  ASCII  codes  together  with  a 
number  of  other  TELNET  control  codes.  To  support  an 
NVT  with  an  IBH  2741  terminal,  it  is  necessary  to  adapt 
a  ccntiol  convention  for  entering  codes  which  are  not 
associated  with  single  keys  on  the  keyboard.  In 
addition,  since  CP/CHS  processes  input  from  a  2741  on  a 
line  at  a  time  terminated  with  a.  newline,  a  means  must 
be  established  for  entering  a  sequence  of  characters 
for  transmission  which  is  not  terminated  with  a  newline 
code. 

When  TELNET  is  '  rated  the  message 

ImKF  CCNTFCL  CHARACTEF 

is  typed-  A  ncn-blank  character  should  then  be  entered 
which  defines  the  character  which,  in  combination  with 
another  character,  will  be  used  to  enter  codes  not 
associated  with  single  keys.  The  control  character  is 
al~c  used  for  other  special  control  functions  as 
described  below. 
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Cedes : 


The  NVT  usually  requires  th?;t  characters  be  transmitted 
in  an  eiqht-bit  ASCII  code.  Since  the  TELNET  command 
is  written  to  process  EBCDIC  codes  ASCII  cedes  received 
are  translated  into  EBCDIC  and  characters  to  be 
transmitted  are  translated  into  ASCII  before  being  sent 
tc  a  serving  site.  Figure  2  gives  the  complete 
definition  of  EBCDIC  indicating  the  EBCDIC  controls  and 
EBCDIC  graphics.  Figure  3  gives  the  codes  for  the 
ASCII  controls  and  graphics.  The  complete  mappiny 
between  9-bit  EBCDIC  codes  and  9-bit  network  ASCII 
codes  is  shown  in  Figure  4.  The  EBCDIC  newline  code 
(NL)  is  mapped  into  the  ASCII  codes  for  the  pair  of 
characters  CP- IF. 

Ihe  fcllvcing  ASCII/EBCriC  mapping  is  used  for  the 
non-EECDIC  graphics: 


ASCII 

EBCDIC 

TILDE 

(7E) 

r 

(A  1) 

NOT 

BAP 

PC) 

= 

<6A) 

OF 

BACK 

SLASH 

PC) 

ss 

(EO) 

CARAT 

(5F) 

•= 

PI) 

GBAVE 

(BO) 

= 

(79) 

LEFT 

BRACE 

PB) 

= 

(8B) 

EIGHT 

BRACE 

PD) 

r= 

(9B) 

LEFT  BRACKET 

(SB) 

- 

(AD) 

FIGHT  EBACKET 

(5D) 

= 

(ED) 

The  ASCII  control  DC 3  (X  •  1 3  * )  maps  to  the  EBCDIC 
control  TK  (X'13»).  The  ASCII  control  NUL  (X*00*)  is 
sent  to  the  terminal  as  the  EBCDIC  code  for  NULL 
(X'CO*)  and  is  not  mapped  into  an  IDLE  (XM7»). 

The  TELNET  control  hide -your-ii  put  is  mapped  into  the 
EECCIC  code  for  bypass  (print  supress)  and  the  TELNET 
control  noechc  is  mapped  into  the  EECDIC  code  for 
restore  (print  restore).  If  the  TELNET  control  for 

echo  is  received,  a  message  is  printed  and  it  is  mapped 
into  an  IDtE.  Similiarly,  if  the  TELNET  control  for 

break  is  received,  a  message  is  printed  and  it  is 
mapped  into  an  IDLE  unless  operation  is  in  EBCDIC 
HALEDUP  mode  in  which  case  the  break  is  used  to 

indicate  that  any  received  characters  should  be  printed 
and  the  keyboard  unlocked  for  input.  If  a  data  mark  or 
an  interrupt  is  received,  no  action  is  taken  except  to 
print  a  message  to  notify  the  user  of  this  occurance. 
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I  rput : 


When  the  control  character  is  entered,  the  following 
character  is  zapped  into  a  different  code  than  that 
which  it  is  normally  mapped  into,  except  when  the 
following  character  is  a  space  or  a  character  not 
defined  to  have  a  meaning  when  preceded  by  the  control 
character.  Figure  5  gives  the  mapping  of  the 
characters  on  a  2741  keyboard  when  preceded  by  a 
ccntrol  character.  The  following  2741  keyboard 
characters  do  not  have  a  different  meaning  when 
preceded  by  the  control  character. 

$  #  *  %  & 

♦  -  = 

•  9  *  » 

!  |  ?  * 

SPACE 

BACKSPACE 

TAB 

When  a  character  is  mapped  into  its  control  code,  the 
control  character  is  mapped  into  the  cede  for  IDLE.  If 
the  control  character  is  entered  as  the  last  character 
before  the  newline  key  is  entered,  the  sequence  of 
characters  entered  is  transmitted  without  the  newline 
code.  That  is,  the  newline  code  is  not  transmitted 
when  it  is  pioceded  by  the  control  character. 

When  the  2741  keyboard  is  unlocked  for  input, 
characters  received  cannot  be  typed  until  the  keyboard 
is  locked  again.  After  a  line  is  entered,  received 

characters  can  then  be  typed.  When  operating  in  full 

duplex  or  ASCII  half  duplex,  a  null  lint  entered  will 
allow  received  characters  to  be  typed  tut  will  not 
causp  the  new  lire  code  to  be  transmitted.  To  cause  a 
null  line,  i.e.,  just  the  new  line  code  to  be 

transmitted,  the  control  character  should  be  entered  as 
the  only  character  in  the  input  line.  In  EBCDIC 

HALFDUP  a  null  line  entered  will  cause  a  null  line  to 
be  transmitted. 
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Cutout: 


ASCII  output  received  from  the  NVT  is  converted  into 
EBCDIC  with  the  sequences  CR-LF  converted  into  IDLF-NL. 
The  EBCDIC  characters  are  then  sent  to  the  terminal. 
Note  that  not  all  128  ASCII  codes  when  converted  to 
EBCDIC  will  print  on  a  2741.  cf  the  9S  ASCII  graphics 
and  the  9  ASCII  controls  which  are  defined  for  the  NVT 
printer,  the  following  are  not  visible  or  audible: 

CARAT 

GRAVE 

EACK  SLASH 

LEFT  BRACE 

RIGHT  BRACE 

LEFT  BRACKET 

RIGHT  BRACKET 

ASCII  CONTROL!  EELI  (EEL) 

ASCII  CONTROL  VERTICAL  TAB  ( HT) 

ASCII  CONTROL  FORM  FEED  (FF) 

ASCII  CONTROL  CARRIAGE  RETURN  (CF) 

Figure  6  shows:  how  the  EECDIC  codes  from  X'40*  through 
X  *  F  F  will  appear  on  a  2741  terminal.  Figure  7  shows 
how  the  EBCDIC  codes  will  appear  when  printed  with  a  PH 
train  on  the  offline  printer  and  Figure  8  shows  how 
these  codes  appear  when  printed  with  a  TN  train. 

Controls : 

If  the  first  character  in  an  input  line  is  the  control 
character  and  the  next  character  is  a  space,  th»  rest 
cf  the  line  is  interpreted  as  a  TELNET  control  command. 
A  control  command  consists  of  a  control  word  and 
parameters  separated  by  spaces.  Controls  are  defined 
which  permit  TELNET  controls  to  be  transmitted  to  the 
serving  site,  allow  input  to  come  from  a  file  or  output 
to  go  to  a  file,  allow  CMS  functions  cr  transient 
commands  to  be  issued,  redefine  the  control  character 
cr  TELNET  mode,  close  connections  or  leave  * he  TELNET 
command  with  the  connections  still  open,  as  well  as 
controls  to  support  a  reader,  punch,  and  printer  with 
RJS  operation.  The  controls  are  described  b^low. 

CONTROL  X 

Where  x  is  the  n^w  control  character 


90 


CLOSE 


lo  close  all  connections  and  guit 

Q  Oil 

lo  leave  TELNET 
EEC DIC 

To  go  into  transparent  mode,  i.e.,  no  translation 

ASCII 

To  translate  input  and  output  to  network  ASCII 

BFEAK 

lo  send  the  TELNET  break  code 

SYNC 

lo  send  the  TELNET  data  mark  code  and  an  interrupt 

AIM 

lo  send  a  TELNET  break  and  a  SYNC 
HIDE-YOUP-INPUT 

Tc  send  the  TELNET  hide  you  input  code. 

NCECHC 

Tc  send  the  TELNET  noecho  code 

ECHC 


Tc  send  the  TELNET  echo  code. 

CPS  command  arg  1  .  .  .  arcN 

To  issue  CMS  core  resident  function  or  transient 
command. 

INPUT  fn  ft 

*  TEBMIN 

*  * 

lo  get  input  from  a  file  If  fn  is  defaulted,  input  is 
reset  to  come  from  the  terminal.  If  fn  is  *  file  input 
resumes  after  the  last  line  read.  After  an  EOP ,  the 
next  line  read  will  be  the  first  line  of  the  file. 

An  external  interrupt  while  input  is  coming  from  a  file 
will  cause  the  line  numb€r  of  the  next  line  to  be  read 
from  the  file  to  be  typed  and  input  to  be  reset  to  come 
from  the  terminal. 
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OUTPUT  f  n  OFF  TERM  INPUT  INCUT 

*  ON  NOTERM  NOINPUT  OUTPt-T 

Tc  write  output  to  the  file  *fn  TERMOUT*.  If  fa  is 
defaulted,  output  is  reset  to  go  to  the  terminal.  If 
fn  is  *,  file  OUTPUT  is  resumed  with  the  same  options 
as  were  last  used. 

For  Output  to  the  Terminal: 

If  the  last  character  is  a  CR,  a  line  with  just  the 
control  character  is  typed  on  the  next  line  (with  a  NL) 

If  the  last  character  is  not  a  NL  or  a  CR,  the  line  is 
typed  without  a  NL  (i.e„,  with  TYPE). 

Fcr  Output  to  a  File: 

If  just  a  NL  is  in  the  line,  just  the  control  character 
is  sent  to  the  file. 

If  the  last  CHAP  is  not  NL  or  CR,  the  control  character 
is  added  after  the  last  character,  except  if  130 
characters  must  be  sent  to  the  file. 

If  the  last  CHAR  is  a  CP,  it  is  included  in  the  file. 
OFF  causes  all  output  to  be  discarded. 

CN  is  the  default,  and  causes  output  tc  qo  to  the 
terminal . 

IEPM  causes  output  to  also  go  to  the  terminal. 

NOTERM  is  the  default,  and  causes  output  to  go  the  the 
file  but  not  tc  the  terminal. 

OUTPUT  is  the  default  and  causes  just  terminal  output 
to  be  put  to  the  file  * F K  termout* . 

INOUT  causes  both  terminal  input  and  terminal  output  to 
be  put  to  the  output  file, 

INPUT  causes  terminal  input  but  not  output  to  be  put  to 
the  output  file. 

NOINPU-,  is  defaulted  and  causes  input  to  not  oo  to  the 
file. 


PURGE 


To  purge  all  output  currently  received  by  the  NCP. 

This  control  is  not  currently  iaplemen ted. 

FEACEF  fn  ft 

*  READER 

To  send  a  job  lo  the  RJS  system  at  UCLA’s  CCN. 

If  fn  and  ft  are  defaulted,  input  will  come  from  the 
card  reader, 

FFINTEF  fn  ft 

*  PRINTER 

To  receive  printer  output  from  the  PJS  system  at  UCLA’s 
CCN. 


To  receive  punch  output  from  the  RJS  sys  :em  at  UCLA’s 
CCN. 

If  fn  and  ^t  are  defaulted,  output  goes  to  the  printer. 

PUNCH  fn  ft 

*  PUNCH 

If  fn  and  ft  .  *.e  defaulted,  output  goes  to  the  punch. 
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i^aa 


TN73-50-I (L. 1)1 


HOST 

SITE 

MACHINE 

SYSTEM 

HOST  NUMBER 
DEC  OCT  HEX 

NMC 

UCLA 

SIGN A- 7 

SEX 

1 

1 

01 

ARC 

SRI 

PDP-10 

NIC 

2 

2 

02 

ucse 

UCSE 

360/75 

0  S/M  VT 

3 

3 

03 

UTAH 

UTAH 

PDP-10 

TENEX 

4 

4 

04 

MULTICS 

MIT 

H-645 

MULTICS 

6 

6 

06 

see 

SEC 

370/155 

ADEPT 

R 

10 

08 

H  AS  V 

HARVARD 

PDP-1C 

4S7i 

9 

1  1 

09 

LL 

LL 

360/67 

CP/CMS 

10 

12 

OA 

CASE 

CASE 

PDP-10 

10/50 

13 

15 

CD 

cmu 

CMU 

P  DP-  10 

TOPS-  10 

14 

16 

OE 

ILLIAC 

AMES 

B-6*00 

? 

15 

1  7 

OF 

AMES 

AMES 

360/67 

TSS/360 

16 

18 

10 

CCN 

UCLA 

360/^1 

0  S/M VT 

65 

101 

41 

SRI 

SRI-AI 

prr-^o 

TENEX 

66 

102 

42 

EEN  A 

BEN 

PDP-10 

TENEX 

69 

105 

45 

DM  CG 

MIT 

PDP-  1C 

ITS 

70 

106 

46 

RAND 

PAND-FCC 

PDP-10 

TENEX 

71 

107 

47 

TX2 

LL 

T  X-2 

APEX 

74 

112 

4  A 

EEN  E 

BEN 

PDP-  10 

TENEX 

133 

205 

85 

MITAI 

MIT 

PDP-10 

ITS 

134 

20  6 

66 

Fiq.  0.1:  Serving  Hosts  on  the  APPA  Network 
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0  0 
0  1 
1  0 
1  0 


0  0 

1  1 

1  1 

C  1 


1  1 

0  0 

1  1 

0  i 


4567 

COOC 


| NHL | Ctc | ES  |  |SP  |  &  |  -  |  |  |  I  “  1  0  I  I 

4 - »4 - 4 - ♦ - ♦ - 4- - 4 - 4- - 4- - 4 - 4- - 4 - 4 - 4-- 

|  SOH  |  DC  1 1  SOS  |  I  I  |  /  I  |  a  I  j  I  o  ,  i  ,  A  |  j  ,  j 

4 - 4- - 4. - 4. - 4. - 4- - 4 - 4--- - 4 - 4- - -4 - 4- - 4 - 4 - -4 - 4 

|  STX  i  DC  2  |  FS  |  SYN  |  |  |  |  |b|k|s]2|B|K|St 

4 - 4- - 4- - 4 - 4 - 4- - 4 - -4 - 4- - 4 - 4* - 4- - 4- - 4-« 

IJETXITM  |  |  |  |  |  |  j  c  |  1  1  t  |  3  ;  C  |  : 

4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - -4 - 4 - 4 - 4 - 4-« 

|  PF  |  FES | EYP | PN  |  |  |  |  |d|m|u|4|D|M|Uj 

4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 

|  FT  |  NL  |LF  |PS  |  |  |  |  J  e  |  n  |  v  |  5  j  E  ,  N  |  y  , 

4 - 4. - 4. - ♦ - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 

|LC  |ES  IETBIOC  |  |  |  |  |f|O|V|6iF’|0|W| 

4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 

|  DELHI  |  ESC  J  EOT  |  {  |  |  |q|p|X|*|G|P|  X| 

4 - 4 - + - 4 - 4. - 4. - 4. - 4. - 4. - 4. - 4. - 4. - 4. - 4 - 4 - 4 

I GE  | CAN |  I  |  |  |  |  I  h  |  q  I  y  |  ®  |  H  |  0  I  Y  I 

4 - 4 - 4 - f - 4 - 4 - 4 - 4 - 4 - 4-  —  4 - 4 - 4 - 4-  ■-* 

I FLF| EH  |  |  |  |  |  |  I  i  I  r  |  2  |  9  |  I  |R 

4 - 4 - 4 - 4 - 4. - 4 - 4  4 - 4 - 4  -  -  -  4 - 4 - 4 - 4  - 

I  SM Pi  |  cc  I  sn  I  I  M  !  I  I  :  I  I  I  I  I  ! 

4 ---4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4— ■ 

I  VT  |  CU  1 1  CU  2  |  CU  3 1  .!$I,|#|{|}|L|J|  I 

4 - ♦ - 4 - 4 - 4 - 4 - 4 - 4  -- -4~ — - - 4 - 4 - 4 - 4  — 

IFF  |  IFS|  |DC4|  <  |  *  J  %  |  a  |  <  |  a  |  r  |  I  I  I  I 

4 - 4-  --4-  --4-  --4--  -4--  -4 - 4 - 4  * - 4 - 4 - 4 - 4  -  -  -  4 - 4 - 4 

|CR  IIGSIENvHNAKI  (|)|_|,|(|)|[|]l  I  I  I 

4-  *-4-  --4  ~-4 - 4 -4-  --4- --4 - 4--- 4 - 4--- 4 - 4 - 4-- -4 - 4 

ISO  I  IPS  I ACK I  l  ♦  I  ;  I  >  |  =  I  ♦  I  ±  I  >  I  #  I  I  I  I 

4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4. - -4 - 4 - 4 - 4 - 4 - 4 

I  si  |  I  OS  |  PEL  |  SUB  |  ||-'|?|"|  +  |«|«|-|  I  I  I 

4 - 4 - 4 - 4 - 4 - 4 - 4 - --4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 


4 - 4 - 4 - 4 - 4 - 4---4 - 4 - 4 

|0|1|2|3|4|5|6|7| 

4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 

Code  Structure 


Fig.  T.2:  The  EBCDIC  Code 
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BOOCOOOOC 
7  0  0  0  0  1  1  1  1 

6  0  0  1  1  0  0  1  1 

5  0  1  C  1  0  1  0  1 

4^71  f - 4 - 4 - 4 - 4 - + - + - * _ 4 

0000  |  NU L  |  DL E  |  ?P  |  0  |  d  j  P  |  |  p  | 

♦  - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 

0001  |  SO  F |  DC  1 1  !  I  1  |  A  |  0  I  a  I  q  I 

4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 

0010  |  ST X | DC 2 1  •'  |  2  |  B  |  P  |  fc  |  r  | 

♦  - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 

0011  I  FT  X I  DC  3 1  #|3|C|S|C|S| 

4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 

0100  | SOT | DC4 |  S|4|D|T|d!t| 

010  1  | EHC I NA K |  %  |  S  |  E  |  U  |  e  |"u"i 

♦  - -4 - 4 - 4 - 4 - 4 - 4- - 4* - 4 

0110  1  AC  K  |  S  Y  N  |  f.  |  6  |  P  |  V  |  f  |  7  | 

4 - -4 - 4 - 4 - 4 - 4 - 4 - 4 - 4 

0111  IBEIIETE,  '|7|G|W|q|v| 

1000  |BS  |CAN  I  (  I  8  I  H  I  X  |  h  |  X  i 

1001  IHT  |EK  I  )  I  9  I  I  I  Y  I  i  |’y7 

4  ---4---4---4 - -4-  - -  4 

101°  !SUB|  *  |  :  |  J  |  z  |  j  |  Z  I 

+  4 - 4 - 4 4 4 + 4 - 4 

1011  |VT  I  ESC |  ♦  |  ;  I  K  |  [  I  k  |  f  I 


4--  - 

-  4 - 

-  4 - 

-  4* 

— 

-  4- 

—  - 

-4- 

- 4- 

-4--> 

-4 

1  100 

I  FF 

1  FS 

1  , 

1 

< 

1 

L 

1 

1 

1 

i  | 

| 

4 - 

- - 

-4--. 

-  4  ■ 

— 

-4* 

-  -  - 

-4  - 

- 4  - 

»  —  « 

-4 - 

-4 

1101 

ICR 

1  - 

1 

= 

1 

M 

1 

1  1 

m 

|  } 

i 

4 - 

-4 - 

-4 - 

-4  - 

— 

-4  - 

... 

-4- 

--4  - 

.  _ « 

-4--. 

-4 

1110 

ISO 

ps 

1  • 

1 

> 

1 

N 

1 

1 

n 

1  - 

l 

4 - 

.4  — 

.4--. 

-  4  - 

-4- 

— 

•  4- 

--4- 

— 

-4--. 

-4 

t - ♦ - ♦ - ♦ - + - + - 4. - + - 4 

1111  |SI  ^US  |  /  I  ?  I  n  I  _  ,  0  , DEL , 


4  4 - 4. - 4 - - 4 - 4 - 4 - 4 

Iq|7|6j5|4|3|2j1| 

4 - 4 - ♦ - 4 - 4 - f - 4 - 4 - f 

Code  Structure 
Fig.  L.":  Tite  USASCII  Cod* 
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TN73-50-I (L.&) 


ASCII 

ASCII 

ASCII 

SYMBOLS 

EBCDIC 

EBCDIC 

DEC 

OCT 

HEX 

HEX 

DEC 

0 

0 

(00) 

KUL 

(00) 

0* 

+ 

l 

1 

(01) 

SOH 

(01) 

01 

2 

2 

(02) 

STX 

(0  2) 

02 

3 

3 

(03) 

ETX 

(0  3) 

<13 

a 

4 

(04) 

EOT 

(37) 

55 

5 

5 

(05) 

ENC 

(2D) 

45 

6 

6 

(06 ) 

ACK 

(2E) 

46 

7 

7 

(07) 

EEL 

(2F) 

47 

8 

10 

(00) 

ES 

(16) 

22 

9 

11 

(09) 

HT 

(05) 

05 

10 

12 

(CA) 

LF 

(2  5) 

37 

11 

13 

(OB) 

VT 

(OB) 

11 

12 

14 

(OC) 

FF 

(OC) 

12 

1  3 

15 

(CD) 

CR 

(OD) 

13 

14 

16 

<0E) 

cO 

(OE) 

14 

15 

17 

(OF) 

;  I 

(OF) 

15 

16 

20 

(10) 

DLE 

(10) 

16 

17 

21 

(11) 

DC  1 

(11) 

17 

18 

22 

(12) 

CC2 

(12) 

18 

19 

23 

(13) 

DC  3 

(13) 

19 

20 

24 

(14) 

DC4 

(30) 

60 

21 

25 

(15) 

NAK 

(3D) 

61 

22 

26 

(16) 

SYN 

(32) 

50 

23 

27 

(17) 

ETE 

(26) 

38 

24 

30 

(IP) 

CAN 

(18) 

24 

25 

31 

(19) 

EM 

(19) 

25 

26 

32 

(1A) 

St!  B 

(3F) 

63 

27 

33 

(IP) 

CTI 

(27) 

39 

29 

34 

(1C) 

FS 

(1C) 

28 

29 

35 

(ID) 

GS 

(ID) 

29 

30 

36 

(IE) 

FS 

(IE) 

30 

31 

37 

(IF) 

US 

(IF) 

31 

Fig.  L.  4  •  TEINET  ASCII/EECIDC  Code  Flapping 
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TtN73-50-I (L.4) 


ASCII 

ASCII 

ASCII 

SYMBOLS 

EBCDIC 

EBCDIC 

DEC 

OCT 

HEX 

HEX 

DEC 

32 

40 

(20) 

SP 

(90) 

64 

:  o 

41 

(21) 

» 

(5A) 

90 

34 

42 

(22) 

« 

(7F) 

127 

35 

43 

(23) 

# 

(7  B) 

123 

36 

44 

(24) 

1 

(5B) 

91 

37 

45 

(25) 

Y 

(6C) 

109 

38 

46 

(26) 

6 

(5C) 

80 

39 

47 

(27) 

i 

(7D) 

124 

40 

50 

(28) 

( 

(4D) 

77 

41 

51 

(29) 

) 

(5D) 

Q  3 

42 

52 

(2A) 

* 

(5C) 

92 

43 

53 

<2B) 

♦ 

(4  E) 

78 

44 

54 

<2C) 

t 

(6  D) 

109 

45 

55 

(2D) 

- 

(60) 

96 

46 

^6 

<2E) 

• 

(4  B) 

75 

47 

57 

(2F) 

/ 

(61) 

97 

'< 

60 

(30) 

C 

(FO) 

240 

49 

51 

(31) 

1 

(FI) 

241 

so 

62 

(32) 

2 

(F2) 

242 

51 

63 

(33) 

3 

(F3) 

243 

r;  ^ 

64 

(34) 

4 

(F4) 

2*4 

53 

65 

(35) 

c 

(F5) 

745 

54 

66 

(36) 

6 

(F6) 

246 

55 

67 

(37) 

7 

(F7) 

247 

56 

70 

<3h; 

6 

(FP) 

248 

57 

71 

(39) 

9 

(FO 

249 

58 

?  7 

(3A) 

• 

<7A) 

122 

59 

73 

(3B) 

• 

(5  E) 

94 

60 

74 

(3C) 

< 

(40 

76 

61 

75 

(3D) 

= 

(7F) 

126 

62 

76 

(3E) 

> 

(6E) 

1  10 

63 

77 

( 3  F) 

7 

(6F) 

111 

Fig. 

L.4:  TELNET  ASCII/EBCIDC 

Code  Hacp 

»i  ng 

(Continued) 
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ASCII 

ASCII 

ASCII 

SYH30LS 

EBCDIC 

EBCDIC 

DEC 

OCT 

HEX 

HEX 

DEC 

64 

100 

(40) 

2 

(7C) 

124 

6  3 

101 

(41) 

A 

(Cl) 

193 

66 

102 

(42) 

E 

<C2) 

194 

67 

103 

(43) 

C 

(C  3) 

195 

68 

104 

(44) 

D 

(C4) 

196 

69 

105 

(45) 

E 

(C5) 

197 

70 

106 

(46) 

F 

(C6) 

198 

71 

107 

(47) 

G 

(C7) 

199 

72 

110 

(48) 

H 

(C8) 

200 

73 

111 

(49) 

I 

(C9) 

201 

74 

112 

(“A) 

J 

(D1) 

209 

75 

113 

(4B) 

F 

(D2) 

210 

76 

114 

<4C) 

.  L 

(D3) 

2  11 

77 

115 

(4D) 

f* 

(04) 

212 

78 

116 

(4E) 

N 

(05) 

213 

79 

1  17 

(4F) 

0 

(06) 

214 

80 

120 

(50) 

P 

(07) 

215 

81 

121 

(51) 

C 

(08) 

216 

82 

122 

(52) 

R 

(09) 

217 

93 

123 

(53) 

S 

(E2) 

226 

84 

124 

(54) 

I 

<E3) 

227 

85 

125 

(55) 

u 

(E4) 

228 

96 

126 

(56) 

V 

(E5) 

2  29 

87 

127 

(57) 

w 

(06) 

2  30 

88 

130 

(58) 

8 

(07) 

231 

89 

131 

(59) 

Y 

(08) 

232 

90 

13  2 

(5A) 

Z 

(E4) 

233 

91 

133 

(5B) 

C 

(AD) 

173 

92 

134 

C  :> 

t 

<«A) 

74  (BACK-SLASH) 

93 

135 

(5D) 

1 

(30) 

189 

94 

136 

(5E) 

(71) 

113  (CARAT) 

95 

137 

(5  0) 

_ 

(60) 

109 

Fig.  I,.  4:  TELNET  ASCII/EBCIDC  Code  Plarping 

(Continued) 


ASCII 

ASCII 

ASCII 

SYK30LS 

EBCDIC 

EBCDIC 

DEC 

CTT 

HEX 

HEX 

DEC 

06 

140 

(60) 

(79) 

121  (GRAVE) 

97 

141 

(61) 

a 

(81) 

129 

98 

142 

(62) 

l 

(82) 

1  30 

99 

143 

(63) 

c 

(83) 

131 

100 

144 

(64) 

a 

(84) 

132 

101 

145 

(65) 

e 

(95) 

133 

1  02 

146 

(66) 

f 

(86) 

134 

103 

147 

(67) 

9 

(87) 

135 

1C4 

150 

(68) 

h 

(88) 

136 

105 

151 

(69 ' 

i 

(99) 

137 

106 

152 

(6A) 

i 

(91) 

145 

1C7 

153 

(OB) 

k 

(92) 

146 

108 

154 

(6C) 

1 

(9  3) 

147 

109 

155 

(6  D) 

w 

(94) 

148 

110 

156 

<6E) 

n 

<°8) 

1  49 

111 

157 

(SF) 

0 

(96) 

1  50 

112 

160 

(70) 

F 

(97) 

151 

113 

16  1 

(71) 

q 

(98) 

152 

114 

162 

(72) 

r 

(99) 

153 

115 

163 

(73) 

c 

(A2) 

162 

116 

164 

(74) 

t 

(A3) 

163 

117 

165 

(75) 

u 

( A4) 

164 

118 

166 

(76  \ 

v 

(A5) 

165 

119 

167 

(77) 

V 

(A6) 

166 

120 

170 

(79) 

X 

(A7) 

167 

121 

171 

(79) 

y 

(A8) 

168 

122 

172 

( 7  A ) 

z 

(A«) 

169 

123 

173 

<7P) 

{ 

(8P) 

139 

124 

1*74 

( 7  C ) 

1 

( 4  F) 

7Q  (^/tR/OR> 

126 

175 

(7  D ) 

} 

(QB) 

155 

126 

176 

( 7  E) 

(5F) 

95  (TILDE/NOT) 

127 

177 

(7?) 

DEI 

(07) 

7 

ASCII 

ASCII 

ASCII 

TELNET 

EBCTIC 

EPCEIC 

EEC 

OCT 

HEX 

CONTROLS 

HEX 

DEC 

128 

100 

(SC) 

DATA-  *1  A  p  K 

(80) 

128 

129 

101 

(8  1) 

BHEAK 

(38) 

56 

13^ 

102 

(S2) 

NOP 

(17) 

23 

IDLE 

131 

103 

(8  51 

NO  EC  HO 

(14) 

20 

RESTORE 

132 

1C4 

(8  4) 

ECHO 

(23) 

3  c 

133 

105 

(8  5) 

HIDF- YOU  F - IN  PUT 

(24) 

36 

BYPASS 

Fig.  1.4:  TELNFT  ASCTI/EBCIDC  Code  flapping 

(Cont  inued) 
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EBCDIC 

EBCDIC 

Cl  NT 

(4  A )  =  ESC 

(27) 

CTL  < 

(4C)  =  IEFT  BRACKET 

(AD) 

CTL  > 

(6E)  =  RIGHT  BRACKET 

(BD) 

CTL  ( 

(40)  =  IEFT  EFACE 

(8B) 

CTL  ) 

(5D)  =  FIGHT  EFACE 

(9B) 

CTL  / 

(61)  =  BACK  SLASH 

(4A) 

CTL  " 

(7F)  =  CARAT 

(71) 

CTI  * 

(7D )  =  GRAVE 

(79) 

CTL  6 

(F6)  =  FS 

(1C) 

CTL  7 

(F7)  =  GS 

(ID) 

CTI  8 

(18)  =  RS 

(IE) 

CTL  9 

(F9)  =  OS 

(IF) 

CTL 

(6D)  =  OS 

(IF) 

CTL  - 

(5F)  =  DEL 

(07) 

CTL  a> 

(7C)  =  NUI 

(00) 

CTL  A 

(Cl)  =  son 

(01) 

CII  B 

(C2)  =  STX 

(02) 

CTI  C 

(C 3  )  =■-  ETX 

(0  3) 

CTL  D 

(C4)  =  EOT 

(37) 

CIL  E 

(C5)  =  ENQ 

(2  D) 

CTL  F 

(C6 )  =  ACK 

(2  £> 

CTL  G 

(C7)  =  BEI 

(2F) 

CTI  K 

(ce )  =  bs 

(10) 

CTL  I 

(C9 )  =  HT 

(05) 

CTL  J 

(D 1 )  =  LF 

(25) 

CTL  K 

(D2)  =  VT 

(OB) 

CTL  L 

(03)  =  FF 

(OC) 

CTL  M 

(C4)  =  CR 

(CD) 

CTL  N 

(05)  =  SO 

OE) 

CTL  O 

(DS)  =  SI 

(OF) 

CTL  P 

(D7)  =  DIE 

no) 

CTL  Q 

/D8)  =  DC1 

(i  i) 

CTL  P 

(09)  =  DC 2 

(12) 

CTL  S 

(E2)  -  DC3 

(13) 

CTL  T 

(E3)  =  DC4 

(3C) 

CTL  U 

(E4)  =  NAK 

(3D) 

CTL  V 

(E5)  =  SIN 

(32) 

CTL  W 

(E6)  =  ETE 

(26) 

CTL  X 

(E7)  =  CAN 

(18) 

CTL  Y 

(18)  =  EH 

(19) 

CTL  Z 

(E9 )  =  SUE 

<3F) 

ASCII 

(IB) 

(5B) 

(5D) 

(7B) 

'7D) 

> C ) 
l5E) 
(60) 

(IC) 
(10) 
(IE) 
(IP) 
PF) 

(7  F) 


'0J) 
(01) 
(02) 
(03) 
f  04) 
(05) 
(OC) 
(07) 
(03) 
(09i 
(CA) 
(03) 
(OC) 
(CD) 
(OS) 
(OF) 

(10) 

(11) 

(12) 

(13) 

(14) 

(15) 

(16) 

(17) 

(18) 
(19) 

( 1  A) 


Fig.  1.5:  2/41  Keyboard  Control  Character  Rapping? 
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:w3Bc«gfct  *fe*^nfiTrir«T  ■  r  -  r*  it  |-»  w- a 


EECDIC 

CTL 

1 

(FI)  = 

BREAK 

CTL 

2 

(F2)  = 

NOP 

CTL 

3 

(F3)  = 

NO  ECHC 

CTL 

a 

(F4)  = 

ECHO 

CTL 

5 

(F5)  = 

HIDE  YOU 

EBCDIC 

ASCII 

(38) 

(81)  - 

(17) 

(82)  - 

(1<M 

(93)  - 

(23) 

(84) 

INPUT  (24) 

(85)  - 

DATA  MASK  (80)  CANNOT  BE  ENTERED  FROM  THE 


2741  KEi';30-ARD  CHARACTERS  DO 
HAVii  A  MEANING  AS  A  CONTFOL: 


•  9  •  i 

!  |  ?  I 

SPACE 
EACKSPACE 
TAB 


Fig.  L.5:  27<n  Keyboard  Control  Character 

(Continued) 


CIRCLE  C 

IDLE 

RESTORE 

BYPASS 

KEYBOARD 

NOT 


Mappings 


]  TN73-50-I (L. 6) 


•y 

X 

4 

5 

6 

7 

8 
9 
A 
B 
C 
D 
£ 

F 


0123456789ABCDEF 


t . 

..<.  (. 

1  . 

t 

•  • 

$.*.) . 

;  •“*. 

........ 

f.%.  . 

>.?. 

• 

•  • 

♦  .5).'  . 

•  .a.b.c.d.e.f.g.h.i. 

•  •  • 

•  « 

•  . j  •  k • 1. 1 .n. o. p.q, r • 

•  •  • 

•  • 

•  •  . s • t . u  . 7. w.x.y.z. 

•  •  * 

•  • 

.  .A.B.C.D.E.F.G.H.I. 

•  •  • 

•  •  • 

•  • 

#  • 

•  .  J .  K  •  L .  M  •  N  •  O  •  P,  Q  .  R  . 

•  •  t 

•  • 

.  .  .S.T.M.V. W.X.Y.Z. 

•  •  • 

•  • 

.0.1. 2. 3. 4. 5. 6. 7. 8. 9. 

•  t  1 

•  • 

Hex  Code  X'xy*  for  Characters 

••y  0123456789 

xx 

06 
07 
08 
09 
10 
11 
12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 


•  •  •  .£•••<• (.+.| 

c . 

•  •  •  •  •  •  •*•%» 

>•? . 

•  ,a, 

b.c.d.e. f.g. h.i.  • 

. j. k.l. o.n, 

o. p.g. r . 

t.u.v.w.x.y.z, 


•  •  . A. B.C. D. E. F.G. 

H.I . J 

K.L.fl.N.OrP.Q.R.  . 

•  •  •  *  .  .S.T.U.V, 

w.x.y.z . 

0.  1.2.  3.4.  5.  C  7.  8.9, 


Decimal  Code  D'xxy*  for  Characters 

Horizontal  Tab 
Lover  Case 
Print  Restore 
New  Line 
Back  Space 
Idle 

Frint  Bypass 
Line  Feed 
Opper  Case 

Hex  Code  X*xy»  and  Decimal  Code  D»xxy»  Control  Codes 
Fig.  1.6:  2741  Chat actet  and  Control  Codes 


HT 

X  *  0  5  * 

= 

D*0C5» 

LC 

X  •  0  6  • 

= 

D*006* 

RES 

X*  14» 

= 

D  *0  20  • 

KL 

X  »  1  5  » 

DTI  * 

ES 

X*  16* 

= 

D»02. 

IL 

X*  17* 

= 

D ' 0  23  * 

BYP 

X  '  2  4  • 

= 

D  *0  36  * 

LF 

X '  2  5  ’ 

D  *  037* 

UC 

X*  36« 

= 

D*  0 54' 
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TN73-5Q-I (L. 7) 


>. 

•  X 

0123456789 

A  B  C  D  E 

F 

0 

.  .A. B.C.D.&. F.G.H.I. 

.  . .  (« 

1. 

1 

.6. J.K.L.M.N.O.P.Q.  P. 

1  9 

2 

T.U.V.W.X.Y.Z. 

.  * . X  .  •>. 

?. 

3 

.0.1 .2. 3. 4. 5. 6. 7. 8.  9. 

: . 

It 

4 

.  .A.B.C.D.E.F.G. H.I. 

•  i .  ^.  (.  +  . 

! » 

5 

.G.J.K.L.M.N.O,T ,Q.  F. 

, 

6 

.-./.S. T.U.V.W.X.Y.Z. 

. f •  %  •  —  • 

? 

7 

.0. 1.2. 3. 4. 5. 6. 7. 8. 9. 

it 

8 

.  .A.B.C.D.E.F.G. H.I. 

.  ..s.  (.  ♦. 

1  • 

9 

.G.J.K.L. H.N.O.P.Q.R. 

.$.♦.)  . ; . 

c 

K 

.-./.S. T.U.V.W.X.Y.Z. 

7  t 

B 

.0.1. 2, 3. 4. 5. 6. 7. 8. 9. 

H 

C 

.  .A.B.C.D.E.F.G. H.I. 

1 

D 

•G.J.K.L.H.N.O.P.Q.  R. 

.  ^ .)  •  i  • 

”i  • 

£ 

.-./.S.T.U.V.  W.  X.Y.  Z, 

.  ,.1.  .  >. 

7  # 

F 

.0.1. 2. 3. 4. 5. 6. 7, 8. 9. 

:.#.a>.~.  =  . 

II 

Hex  Code  X*xy» 


••y  0123456769 

xx 

00  .  .A.B.C.D.E.F.G. H.I. 

01  .  ...<.  (.♦.j.fi.J.K.I.. 

02  .H.N.O.P.Q.R.  -$.*.) . 

03  .  ;.-».-*/«S.T.U.V.W.X* 

04  •  Y  .  2  .  .  ,.X.  0.1. 

05  .2. 3, 4. 5. 6. 7. 6. 9.:.#. 

06  , a, 1 .  = ,  ”  .  .A.B.C.D.E. 

G7  .F.G.H.I.  . ,  |  . 

03  .6.  J.K.L.M.N.O.P.Q.  3. 

09  .  .i.*.)  .  -./.S.V. 

10  .U.V.W.X.Y.7,  %.  . 

11  1. 2,3. 4.5. 6.7. 

12  .8.9.:. #. a. .A. 

13  .B.C.D.E.F.G*  H.I.  ... 

14  .<.(.♦. |  .G.J. K.L.H.N. 

15  .C.P.Q.P.  .$.*.)  . 

16  .-./.S.T.U.V.  W.X.  Y.2. 

17  .  .>.7.0.1. 2. 3. 

18  .4. 5. 6. 7. 8.9. 

19  .  =  .".  .A.B.C.D.E.F.G. 

20  .H.I  .  ...<•(.♦•  |  .  S.  J. 

21  .K.L. H.N.O.P.Q.R.  .$. 

22  .*.)  .  ;.-.-./.  S.T.U.V. 

23  .W.X.Y.Z.  .>.?. 

24  .0. 1. 2. 3. 4. 5. 6.7. fi. 9. 

25  .=.". 

Decimal  Code  D'xxy' 


Fig.  L.7:  code  for  Characters  on  a  PN  Print  Train 
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•y 

X 

0 

1 

2 

3 

4 

5 

6 
7 
6 
9 
A 
E 
C 
D 
E 
F 


•  oy 

0 

1 

2  3 

4 

5 

6 

7 

8 

9 

XX 

00 

• 

•  • 

01 

• 

•  • 

02 

• 

•  • 

03 

• 

•  • 

04 

• 

•  -# 

05 

• 

•  • 

06 

• 

•  • 

07 

• 

•  • 

• 

.< 

-  ( 

♦ 

•  1 

08 

.6 

•  • 

*  9 

.  ! 

.$ 

•  » 

,  - 

*/ 

10 

«• 

•  • 

•  * 

% 

11 

.> 

■> 

•  • 

12 

• 

.a 

• 

,  = 

.a 

13 

.  fc 

.  c 

.  d  -  e 

.  f 

g 

.  h 

•  i 

.  { 

14 

.  < 

.  < 

.♦.+ 

3 

.  k 

.1 

□ 

.  n 

15 

.o 

•P 

.q.r 

} 

.  □ 

, ) 

± 

•  a 

16 

• 

t  0 

.s.  t 

.  u 

V 

•  V 

.  X 

y 

.2 

17 

• 

,  L 

•  r  •  [ 

.  > 

* 

,  0 

t  i 

z 

,  3 

18 

#  4 

#  S 

,6.  7 

,  8 

.  j 

1 

•] 

19 

.* 

.  — 

.  .A 

.B 

C 

.  D 

.E 

.6 

20 

.  H 

.  I 

•  • 

.J 

21 

.  K 

.L 

.  M .  N 

.0 

P 

•  C 

.  R 

22 

• 

•  • 

.  5 

.T 

n 

.V 

23 

.  W 

.X 

.  Y .  2 

24 

.0 

•  1 

.2.3 

.  4 

5 

.  6 

!  7 

8 

\s 

25 

• 

• 

•  • 

Decimal  Code  D'xxy* 

Fig.  L.8:  Code  for  Characters  on  a  PN  Print  Train 
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